To just add my personal comment.
Those options are discussed for a reason.
There are problems within the realm of the spec
that some corner cases have not been really covered
which normally do not occur but from time to time happen
(like issues with infinite queue sizes under certain application
environments, or for instance
in the future dealing with fieluploads before jsf 2.1, or for instance
I just added an option to allow other error outputs for development
besides alert (like it was defined in the spec) for Development stage)
We saw it sort of necessary to allow the users to enable those options
because it is better to allow sane overrides at certain points than to
force the user to hack the code to get some features up and running for
certain corner cases. (which is always possible with javascript due to
no having any isoltion whatsoever)
As for the portability trap, I dont really see it, everyone who uses a
custom option must be aware that this might induce a portability problem
in the long run, but this option has to be used fully understanding it
since it is outside of the spec, and leaving them out definitely has
to cause a fully spec compliant behavior!
Besides that the entire configuration stuff is used in two different
areas to give a short explanation
we have a global configuration which also binds the layers (mainly
api->impl->delegators for impl, and also allows to enable settings on a
global level)
we have local configuration options which can override the global ones
to allow settings on a local per request layer!
So what does this mean, first of all, none of this should be used in
normal circumstances, in this case we should be fully spec compliant
but then you can alter certain things on a need to need base, like
changing the spec alert behavior to console.log for debugging purposes,
or you can change your impl on the fly with a different one, or you can
change the currently dependency less xhr transport delegate to a dojo
based one, if preferred, or you can alter the queue size.
We are simply opting for such things because of corner cases and to
leave the users/companies using the code options open to add their own
implementations without having to hack the code.
But everyone doing such things must be aware of the risks this might
introduce!
This is not the first time we are doing this, as pointed out earlier, we
have in other points those configuration options as well, just look at
the list of context parameters myfaces provides to enable certan
behavior like controlling the state history, or as below pointed out
to how the serialisation has to be performed!
Nothing of those has introduced any portability issues so far because
people understood that this was behavior which should ease the life
but is outside of the spec!
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.
