Re: [jsr-314-open] h:outputScript doesn't work inside composite components

2009/5/11 Jim Driscoll <Jim.Driscoll(a)sun.com <mailto:Jim.Driscoll@sun.com>> On 5/11/09 9:30 AM, David Geary wrote: 2009/5/11 Ryan Lubke <Ryan.Lubke(a)sun.com <mailto:Ryan.Lubke@sun.com> <mailto:Ryan.Lubke@sun.com <mailto:Ryan.Lubke@sun.com>>> On 5/11/09 7:40 AM, David Geary wrote: I have a login composite component that looks like this: <composite:interface>...</composite:interface> ... <composite:implementation> <script type="text/javascript"> function checkForm(form) { var name = form['#{cc.clientId}:name'].value; var pwd = form['#{cc.clientId}:password'].value; if (name == "" || pwd == "") { alert("Please enter name and password."); return false; } return true; } </script> ... </composite:implementation> I have components with "name" and "password" component ids in a form in the ... part of the implementation. That works fine. However, if I pull the JS out into its own file, and do this: <composite:interface>...</composite:interface> ... <composite:implementation> <h:outputScript library="components/login" name="login.js"/> ... </composite:implementation> h:outputScript puts the JS in the page, but the JS no longer works because the expression cc.clientId evaluates to an empty string. That's a bug, is it not? No, I don't believe it is. The javascript file will be served in a separate request. There is no way to determine the component at that time. That's what I figured, but that's not going to be obvious to the average developer. This is a pretty serious violation of the principle of least astonishment, and JSF has enough of those violations, IMO. If there's no way to make it work, it should be documented, preferably in the pdl (or is it vdl now?) docs that h:outputScript will not work when the corresponding JS references a composite component. I agree that we should document how to do this: Which is why I wrote a demo that does this (basic-ezcomp/spinner-final) - and blogged about it http://weblogs.java.net/blog/driscoll/archive/2008/11/jsf_20_writing.html The problem is not solvable the way that you think it is: I struggled with this too, until Ryan walked me through it. The problem is one of the web, not one of the JSF, exactly. So, look at it this way: The JavaScript file is served ONCE, from ONE known address. This is good - it allows us to cache the javascript file. This is bad - because we do the # variable substitution *before* we serve the file, we can't do #{cc} substitutions in it, that file could (and will) be shared across views - and even across different websurfing sessions, after all, that's the whole point of the resource mechanism... Efficient use of caching for resources. So, how to address this? One way is in the demo - just set the cc.clientId as a context, and use that context in the function calls. In a different demo (ajax-switchlist) I save that context into state, and use that in each call. Either way works, and both require about four lines of (javascript) code. If you make it so that we make those substitutions into the javascript file, then you also need to output that javascript file with a view unique name. And that's probably a bad idea for most uses, since that shoots caching in the head. We could add a "perview" attribute to each resource, I guess, but since the workaround is so easy, once you know it, and the cost is the loss of caching, I'd argue this isn't a good idea. I urge you to run through the demos I wrote (basic-ajax, basic-ezcomp, basic-ajax-edittext, ajax-switchlist) - they're all small, and in each of them, I try to tackle one small problem and solve it. In many of them, I ran into problems just like this, and worked through them. They're not documented (except in blogs), but they are all small pieces of code. Okay, I'll do that. Thanks for the insights--I hadn't stopped to think about caching. david Jim