8:03 a.m.
So, I got a chance to discover more about RichFaces today, attending a
tutorial by Max Katz.
Autoupdate can also be thought of as "always render" - it's the process
of marking out certain id's to always be rendered on any ajax request.
I can now say that, no, we don't support autoupdate functionality -
while a page author doesn't really need this functionality, it's
possible to imagine a use case for it as a component library author -
and in that case, while there's hacky things you can do to almost get
there, it won't really be possible with the existing APIs.
Since in an earlier message, I said that I wasn't aware of anything in
particular that couldn't be done with the API, well, here's one use case.
Adding such an API would be pretty easy:
void jsf.ajax.addAlwaysRender(String id)
I'll file a spec RFE for this (there seems to not be one!), but I was
wondering:
What's the context/history behind this not being included in JSF 2.0?
Can anyone elaborate?
Jim
P.S. Filed bug 629 on this topic.
9:37 a.m.
We probably didn't get to it because we were trying to nail the
underlying framework
and its areas of standardization (that will hopefully promote component
interoperability - yes I'm still hopeful ;-) ).
I suspect there will be other "nice to haves" that can be added in 2.1.
Maybe other folks from the Ajax sub group or EG have some additional
thoughts.
-roger
Jim Driscoll wrote:
So, I got a chance to discover more about RichFaces today, attending
a
tutorial by Max Katz.
Autoupdate can also be thought of as "always render" - it's the
process of marking out certain id's to always be rendered on any ajax
request.
I can now say that, no, we don't support autoupdate functionality -
while a page author doesn't really need this functionality, it's
possible to imagine a use case for it as a component library author -
and in that case, while there's hacky things you can do to almost get
there, it won't really be possible with the existing APIs.
Since in an earlier message, I said that I wasn't aware of anything in
particular that couldn't be done with the API, well, here's one use case.
Adding such an API would be pretty easy:
void jsf.ajax.addAlwaysRender(String id)
I'll file a spec RFE for this (there seems to not be one!), but I was
wondering:
What's the context/history behind this not being included in JSF 2.0?
Can anyone elaborate?
Jim
P.S. Filed bug 629 on this topic.
10:07 a.m.
Maybe other folks from the Ajax sub group or EG have some additional
thoughts.
I've got more thoughts on this, but for the moment only have time for a
few comments... I agree with your representation of how this played out
- ie. the folks most involved in defining the Ajax APIs were very much
focused on getting a strong foundation in place. From my perspective,
this was a fairly grueling effort in which we did our best to take into
account requirements of the (competing) JSF Ajax frameworks at the
table. Personally, I was very impressed with the level of cooperation
between the various players.
Note that there was also a fairly late overhaul - ie. the generalization
of our Ajax solution into the Behavior API, which took a tremendous
amount work performed under quite a bit of pressure due to the impending
spec deadlines. At the time there was general agreement that nailing
down the core APIs and providing points of extensibility was more
important that ensuring that every feature requirement of each of the
JSF Ajax frameworks was directly addressed by the spec.
I think we have accomplished quite a bit with the JSF 2.0 Ajax APIs.
Sure, there is more work to do. As long as we are diligent about
identifying missing requirements or ways to improve interoperability, we
should be in good shape moving forward.
And I'm sure ADF Faces will follow suite (if they haven't
started
already).
Yes indeed. :-)
Actually, one of the reasons why I have been slow in responding to EG
emails recently is because I am doing my best to stay focused on
developing our ADF Faces/JSF 2.0 integration strategy.
Andy
10:48 a.m.
I don't know the context/history... but want to voice some reservation
regarding this "feature".
I hope we have a way of skipping this for cases such as:
1) If my Ajax response is not going to be handled by JSF2's standard
JS. This is obvious... but I thought I'd state it anyway.
2) If I am making several Ajax requests in a short amount of time (i.e.
immediately after the page is loaded), I would obviously not want to
re-render all the auto-update components several times.
3) If I require a fast, light-weight request (i.e. auto-complete text box).
"Auto-update" seems like a great "push" feature, or polling feature
that
is separate from other Ajax requests. If I understand it correctly,
having an "always render" component seems a little excessive.
Thanks!
Ken
Jim Driscoll wrote:
So, I got a chance to discover more about RichFaces today, attending
a
tutorial by Max Katz.
Autoupdate can also be thought of as "always render" - it's the
process of marking out certain id's to always be rendered on any ajax
request.
I can now say that, no, we don't support autoupdate functionality -
while a page author doesn't really need this functionality, it's
possible to imagine a use case for it as a component library author -
and in that case, while there's hacky things you can do to almost get
there, it won't really be possible with the existing APIs.
Since in an earlier message, I said that I wasn't aware of anything in
particular that couldn't be done with the API, well, here's one use case.
Adding such an API would be pretty easy:
void jsf.ajax.addAlwaysRender(String id)
I'll file a spec RFE for this (there seems to not be one!), but I was
wondering:
What's the context/history behind this not being included in JSF 2.0?
Can anyone elaborate?
Jim
P.S. Filed bug 629 on this topic.
5364
days inactive
5364
days old
jsr-314-open-mirror@lists.jboss.org
3 comments
4 participants
participants (4)
-
Andy Schwartz -
Jim Driscoll -
Ken Paulsen -
Roger Kitain