myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wessendorf <mat...@apache.org>
Subject Re: f:ajax and MyFaces extensions
Date Fri, 24 Apr 2009 07:25:17 GMT
On Fri, Apr 24, 2009 at 9:17 AM, Ganesh <ganesh@j4fry.org> wrote:
> Hi,
>
> With all the community feedback in favour of t:ajax I gave it some more
> thought and came up with a solution: tomahawk can bring it's own myfaces.js
> file that t:ajax builds on. This solution does have a whole bunch of
> benefits:
>
> - the optimization options become available to Mojarra users
> - Mojarra Javascript bugs don't affect t:ajax users
> - view options like disable (naming elements to disable while xhr runs) and
> loadingbar (a turning snake to display while xhr is running) can be
> integrated with t:ajax
> - the options can be used naturally <t:ajax execute="..." render="..."
> pps="..." disable="..."/>, no more need for a myfaces subarray
> - defaulting can include pps="true" and queuesize="1"
> - myfaces.js would include a function myfaces.ajax.request that is triggered
> by t:ajax. The parameters of myfaces.ajax.request could also be set up more
> naturally, the need for a myfaces subarray would drop out:
> myfaces.ajax.request(execute:"..." render:"..." pps:"..." disable:"..."),
> thus aligning the procedural and the declarative solution
>
> If we decide to go this way I would remove the special options from the
> cores Javascript too.
>
> We've got 4 different proposed solutions now:
>
> 1.) extra options in t:ajax and myfaces.ajax.request
> 2.) optimization options as attributes of f:ajax
> 3.) optimization options within f:attributes nested in f:ajax
> 4.) a separate taglibrary with a single tag mf:ajax included with the core
>
> Should I set up a vote on this?

please!
You already know my vote, right ? :)

>
> Best Regards,
> Ganesh
>
> Cagatay Civici schrieb:
>>
>> Then just document t:ajax is an extension that's not compatible with RI.
>>
>> On Thu, Apr 23, 2009 at 5:39 PM, Ganesh <ganesh@j4fry.org
>> <mailto:ganesh@j4fry.org>> wrote:
>>
>>    Hi,
>>
>>    The options don't work with the RI, so t:ajax isn't feasable afaik.
>>
>>    Best Regards,
>>    Ganesh
>>
>>    Cagatay Civici schrieb:
>>
>>        The legacy way myfaces followed for a long time is to have
>>        standards in core and extensions in tomahawk. Isn't it the
>>        whole idea of t:inputText, t:dataTable?
>>
>>        So I'm -1 as well for that kind of extensions in core so
>>        t:ajax sounds fine.
>>
>>        Cagatay
>>
>>        On Thu, Apr 23, 2009 at 5:06 PM, Ganesh <ganesh@j4fry.org
>>        <mailto:ganesh@j4fry.org> <mailto:ganesh@j4fry.org
>>        <mailto:ganesh@j4fry.org>>> wrote:
>>
>>           Hi,
>>
>>           How would you get the options into tomahawk? They rely on the
>>           Javascript core and tomahawk needs to run with the RI.
>>
>>           What is myfaces:ajax? Is it another namespace included with the
>>           core, containing only a single tag?
>>
>>           It seems confusing for the users to have additional options
>>           available on jsf.ajax.request which cannot be triggered
>>        when using
>>            the declarative approach without adding an extensions jar.
>>
>>
>>           Best Regards,
>>           Ganesh
>>
>>           Werner Punz schrieb:
>>
>>               Sorry I have not read the original post here....
>>
>>
>>               I agree with Simon in the regard, that we should not
>>               add the options thing to our standard f:ajax tag, but
>>        would go
>>               even further to add nothing to f:ajax at all which is
>>        outside
>>               of the spec!
>>
>>               The reason for this is, it would break the behavior we have
>>               done in the past and people relied upon. Up until now
>>        we added
>>               extensions on tag level via our own tag(Partially
>>        enforced by
>>               the TCK)
>>
>>
>>               So -1 to adding anything custom to f:ajax
>>               +1 to enable the users to access our internal custom
>>        options
>>               with myfaces:ajax or t:ajax
>>
>>               Sorry for my lengthy post before, which was semi off
>>        topic, I
>>               should had read the entire conversation before posting
>>        a reply.
>>
>>
>>               Werner
>>
>>
>>               Ganesh schrieb:
>>
>>                   Hi Simon,
>>
>>                   Avoiding any change of behaviour within myfaces special
>>                   options doesn't seem adequate to me. EVERY myfaces
>>        option
>>                   will change the behaviour. MyFaces 1.2 supports
>>
>>                   org.apache.myfaces.SERIALIZE_STATE_IN_SESSION
>>
>>                   With this option set some applications may add non
>>                   serializable beans to the state, breaking compatibility
>>                   with other implementations. It is obvious to the
>>        developer
>>                   that
>>                   options starting with myfaces can induce compatibility
>>                   problems.
>>
>>                   Imho you hit the point when you said before that core
>>                   extensions should be avoided
>>                   "if they do fundamentally change the behaviour of the
>>                   app". Standard applications should be remain
>>        portable in
>>                   spite of implementation options set.
>>                   Here's a short discussion on the portability issues
>>        of the
>>                   proposed extension options:
>>                   - With myfaces:pps set to true applications that
>>        evaluate
>>                   request parameters within phase 5 could change their
>>                   behaviour.
>>                   - With myfaces:errorlevel set to WARNING
>>        applications that
>>                   have a Javascript part
>>                   that relies on some errorlisteners being triggered
>>        could
>>                   change behaviour.
>>                   - With myfaces:queuesize set to 1 it's hard to
>>        think of an
>>                   application that would change behaviour. Maybe a button
>>                   that increases a counter by 1 (or scrolls a list by 1
>>                   page) on each click would miss some of the clicks
>>        if the
>>                   user has a "quick thumb".
>>                   I cannot think of a szenario where myfaces:queuesize=1
>>                   would make an application run
>>                   into errors (can you?).
>>
>>                   I think all 3 of these are special cases where minor
>>                   changes of behaviour occur, none of them fundamentally
>>                   changes the behaviour of the app.
>>
>>                   Best Regards,
>>                   Ganesh
>>
>>                       Adding behaviour-changing features to standard
>>        tags is
>>                       setting a
>>                       portability trap for users, where their app will
>>                       silently fail to run
>>                       correctly when executed on a different JSF
>>                       implementation. That seems
>>                       unacceptable to me, even if the TCK cannot
>>        technically
>>                       detect it.
>>
>>                       So for the two params you are proposing which
>>        are just
>>                       performance
>>                       tweaks, just attributes on f:ajax, or using nested
>>                       f:attribute seems ok.
>>                       But for the other one (queueLength?) I would
>>        strongly
>>                       recommend an
>>                       mf:ajax or mf:attribute tag be created.
>>
>>
>>
>>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Mime
View raw message