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
