Hi 2010/5/9 Ganesh <[email protected]>
> Hi Leo, > > +1, good approach! > > 1 question: Why do 1.+2. require a h:head to be present while 3.-5. render > jsf.js inline? Wouldn't it be possible to *always* try and push it to h:head > and if h:head is not defined *always* fall back to inline? > > That's the idea. In few words, if a custom client behavior or f:ajax tag is used, register jsf.js script on head target and render them at h:head, but if those resources are not rendered, fall back to inline. Note any resource could only be rendered once per view. regards, Leonardo > Best regards, > Ganesh > > Leonardo Uribe schrieb: > > Hi >> >> Checking some code related to client behavior api, I notice that it is not >> very clear the conditions to render jsf.js script on a page. >> >> Right now we have an open issue (see MYFACES-2687) but we need to discuss >> this one first before solve it. >> >> In few words, myfaces is doing the following: >> >> 1. If f:ajax tag is used on the current view, register the script >> automatically to be rendered on h:head. >> 2. When h:commandLink has some code in onclick, renders the script inline >> if it was not rendered before. >> >> Mojarra do this: >> >> 1. If f:ajax tag is used on the current view, register the script >> automatically to be rendered on h:head. >> 2. When h:commandLink has some code in onclick, renders the script inline >> if it was not rendered before. >> 3. When h:commandButton is used and has nested f:param tags, renders the >> script inline if it was not rendered before. (related to MYFACES-2704 >> <f:param> in <h:commandButton> not rendered properly). >> 4. If no <h:head> is found on the current view, it adds a FacesMessage or >> log a message saying some scripts has not been rendered. >> >> The problem is both strategies believe that f:ajax is the only client >> behavior that needs this script. In fact, all components that implements >> ClientBehaviorHolder interface and has an attached ClientBehavior and a >> script pointing to the same javascript event requires it, because in this >> case we need to render a call to jsf.chain(). For example: >> >> <h:inputText onkeydown="doSomething()"> >> <x:customClientBehavior event="keydown"> >> </h:inputText> >> >> We also assume that the custom ClientBehavior does not use by default >> jsf.js methods. Since ClientBehavior is part of the new jsf 2.0 api, in my >> opinion we should assume the opposite, the presence of a ClientBehavior on >> the current page activate render jsf.js script as f:ajax tag. >> >> The proposal is do the following on myfaces: >> >> 1. If f:ajax tag is used on the current view, register the script >> automatically to be rendered on h:head. >> 2. If a custom behavior is used on the current view, register the script >> automatically to be rendered on h:head (all custom behaviors without custom >> TagHandler use BehaviorTagHandlerDelegate, so the code should be there) >> 3. Check for client behaviors and render jsf.js inline (only if necessary, >> in other words if the component has attached a client behavior) before any >> markup is rendered on all renderes of ClientBehaviorHolder instances. In >> this case there is warrant the client behavior will work. >> 4. When h:commandLink has some code in onclick, renders the script inline >> if it was not rendered before. >> 5. When h:commandButton is used and has nested f:param tags, renders the >> script inline if it was not rendered before. (related to MYFACES-2704 >> <f:param> in <h:commandButton> not rendered properly). >> >> If no objections I'll commit this proposal soon. >> >> Suggestions are welcome. >> >> regards, >> >> Leonardo Uribe >> >> > -- > "There are two kinds of people in the world, those who believe there are > two kinds of people and those who don't." > — Robert Benchley >
