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>>
>
>
> 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