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.
