Re: f:ajax and MyFaces extensions

[Werner Punz]

Ok let me get this straight...

You propose to route to our jsf_impl if a mojarra user tries to use the tag.
That needs some adjustments, because we call jsf.js from within our 
_impl code.

So we need to add a loose coupling of those calls as well by adding
an adaptor/delegator pattern for those!

(I am thinking of adding another configuration option which can change
the namespace of the api callback so that we can reroute them directly
into our impl_ class on the fly)

I am ok with it... so +1 from my side, I dont expect any sideffects if 
we can straighten this out!

Anway it seems that this is the usecase where we first see the 
advantages of being modular and loosely coupled in our code instead of 
trying to push everything into jsf.js  :-)


Werner



Ganesh schrieb:
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?

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 <gan...@j4fry.org 
<mailto:gan...@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 <gan...@j4fry.org
        <mailto:gan...@j4fry.org> <mailto:gan...@j4fry.org
        <mailto:gan...@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.