myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: [core] conditions to render jsf.js script
Date Tue, 11 May 2010 11:06:24 GMT
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 <ganesh@j4fry.org>

> Wow, thank you for the clarification.
>
> Leonardo Uribe schrieb:
>
>> Hi
>>
>> 2010/5/10 Ganesh <ganesh@j4fry.org <mailto:ganesh@j4fry.org>>
>>
>>    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 <jakob.korherr@gmail.com
>>        <mailto:jakob.korherr@gmail.com> <mailto:jakob.korherr@gmail.com
>>
>>        <mailto:jakob.korherr@gmail.com>>>
>>
>>
>>           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 <ganesh@j4fry.org <mailto:ganesh@j4fry.org>
>>        <mailto:ganesh@j4fry.org <mailto:ganesh@j4fry.org>>>
>>
>>
>>
>>               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

Mime
View raw message