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.
