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