Hi 2010/5/9 Jakob Korherr <[email protected]>
> Hi Leo, Ganesh, > > Yes, good approach, Leo :) > > However I think we should do what Ganesh proposed, that means we should > fall back to an inline rendering of jsf.js if h:head is not present in > addition to adding a FacesMessage and/or log entry. > > The algorithm proposed does not include add a FacesMessage and/or a log entry. I have attached a patch of the changes proposed to MYFACES-2687. http://issues.apache.org/jira/browse/MYFACES-2687 > The problem, Ganesh, with pushing it to h:head is, that the only place > where we can really check if a ClientBehavior, which will also be rendered, > is attached to a ClientBehaviorHolder is the renderer of that > ClientBehaviorHolder. And at that time h:head has already been rendered. A > check before that would require a tree traversal, which would make it slow, > I guess. Or were you thinking of another method to accomplish this? > > The idea is put some lines that check if the resource was rendered or not on every renderer that renders ClientBehaviorHolder instances. Do a tree traversal is not safe. Instead, the idea is take advantage of the algorithm specified for script and stylesheet resources (note any resource could only be rendered once per view). regards, Leonardo Uribe > Regards, > Jakob > > 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? >> >> 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 >> > > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at >
