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.
