We'll have to work on keeping the performance overhead low, and then we of course want the state in and with AJAX requests.
Craig, your solution can only be an optional low performance overhead alternative, but never the base of doing AJAX with JSF. regards, Martin On 4/28/06, Jacob Hookom <[EMAIL PROTECTED]> wrote: > 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 > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
