I know the world doesn't revolve around JSF, but you are promoting them
as JSF components-- :-)
I agree that the RPC approach (Shale/Seam Remoting) is extremely valid,
but as a mashup with a UIComponent, there's an obvious disconnect.
That's my only point, why should one EL expression work but not the
other on the same component? There's no documentation coming out of the
blueprints that notes that point (at least that I've seen).
It would be ignorant of me to say that PPR is the only solution offered
by JSF (we'll be covering both at J1), but it is much more natural for
JSF components/developers with acceptable overhead without dealing with
AJAX/transport negotiation within your business code or UI code.
Keep in mind our original presentation title was: AJAX Done Right?
(note: the question mark ;-)
Craig McClanahan wrote:
On 4/27/06, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>*
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
I think the approaches of the blueprint components are highly
faulty-- especially with the use of dojo.bind. You are dealing
with pure URI negotiation which is orthogonal to the communication
capabilities of JSF. Example, the autocomplete example uses Shale
Remoting via an EL expression-- but doesn't carry context, so
yeah, you can put #{ foo.suggest} but only if 'foo' is globally
available which is a huge gotcha for developers and pushing the
JSF solution back to where we were with JSP 2.0 and JSF 1.1 issues
again with the disconnect.
Jacob,
It might surprise you to hear *me* say something like this, but the
entire AJAX world does *not* revolve around JSF :-0.
Don't get me wrong. The use cases for wanting to partially update the
state of the JSF component tree are perfectly valid -- and the stuff
you guys are looking at with Avatar is perfectly reasonable (can you
*please* settle it down so I can use it in Shale Remoting, for JSF 1.1
as well as JSF 1.2, in addition to what's already there :-). But this
is by no means an approach that is universally applicable.
Take the use case you are complaining about here (the auto complete
component having to forward the method binding expression to call the
end user's method). Yes, that is necessary because this particular
implementation does not assume that it has access to the JSF component
tree (from which it could acquire the appropriate expression). And,
it would be perfectly reasonable to want an auto complete component
that *allowed* me to do such a thing.
But to *require* me to do that? Nah ... there are valid tradeoffs
between sending extra state information (and avoiding the
computational effort required to restore the component tree) and not
doing so. That's not for the component author to predict -- an ideal
auto complete text field component would support *both* strategies.
To say nothing of a Java back-end for non-JSF based applications,
which care not a whit about JSF component state :-). Don't forget
that this world exists too, and Shale Remoting as it currently exists
supports out of the box.
Craig
--
--------------------------
Sent from my FrankenBerry Wireless Handheld
