Hi 2010/5/10 Ganesh <[email protected]>
> Hi Leo, > > I'm not sure we're talking about the same thing: The point Andrew and me > where making is that it could be good to render jsf.js inline for f:ajax and > and custom behaviours if no h:head is present. Was this what you where > talking about? > > Yes, the condition proposed to do that is put a code on every renderer that renders ClientBehaviorHolder instances, detecting if the component has a ClientBehavior, and if so, render it inline before any other markup. regards, Leonardo Uribe > > Best regards, > Ganesh > > > Leonardo Uribe schrieb: > >> Hi >> >> 2010/5/9 Jakob Korherr <[email protected] <mailto: >> [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] <mailto:[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 >> >> >> > -- > "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 >
