Hi,
With all the community feedback in favour of t:ajax I gave it some more
thought and came up with a solution: tomahawk can bring it's own
myfaces.js file that t:ajax builds on. This solution does have a whole
bunch of benefits:
- the optimization options become available to Mojarra users
- Mojarra Javascript bugs don't affect t:ajax users
- view options like disable (naming elements to disable while xhr runs)
and loadingbar (a turning snake to display while xhr is running) can be
integrated with t:ajax
- the options can be used naturally <t:ajax execute="..." render="..."
pps="..." disable="..."/>, no more need for a myfaces subarray
- defaulting can include pps="true" and queuesize="1"
- myfaces.js would include a function myfaces.ajax.request that is
triggered by t:ajax. The parameters of myfaces.ajax.request could also
be set up more naturally, the need for a myfaces subarray would drop
out: myfaces.ajax.request(execute:"..." render:"..." pps:"..."
disable:"..."), thus aligning the procedural and the declarative solution
If we decide to go this way I would remove the special options from the
cores Javascript too.
We've got 4 different proposed solutions now:
1.) extra options in t:ajax and myfaces.ajax.request
2.) optimization options as attributes of f:ajax
3.) optimization options within f:attributes nested in f:ajax
4.) a separate taglibrary with a single tag mf:ajax included with the core
Should I set up a vote on this?
Best Regards,
Ganesh
Cagatay Civici schrieb:
Then just document t:ajax is an extension that's not compatible with RI.
On Thu, Apr 23, 2009 at 5:39 PM, Ganesh <gan...@j4fry.org
<mailto:gan...@j4fry.org>> wrote:
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 <gan...@j4fry.org
<mailto:gan...@j4fry.org> <mailto:gan...@j4fry.org
<mailto:gan...@j4fry.org>>> 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.
