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]> 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]>> 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. >> >> >> >> >>
