Hi, However this also means that custom component libraries (e.g. Trinidad) that have ClientBehaviorHolder-components have to implement the logic to detect and render jsf.js on their renderers too, right?
Can we do something better here or is this a spec problem/issue? Regards, Jakob 2010/5/10 Ganesh <[email protected]> > Wow, thank you for the clarification. > > Leonardo Uribe schrieb: > >> Hi >> >> 2010/5/10 Ganesh <[email protected] <mailto:[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]> <mailto:[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]> >> <mailto:[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 >> >> >> > -- > "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
