On Fri, Apr 24, 2009 at 9:17 AM, Ganesh <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>> 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
