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