I guess I look at this stuff much differently with JSF. Watching Ted
Neward's interview on SOA
(http://www.theserverside.com/news/thread.tss?thread_id=39757), it got
me thinking that these AJAX solutions are doomed to pursue the same route.
If we setup a good story for partial processing/rendering on the server,
then there's no real need for intermediary RPC solutions from a pure
data standpoint. Send up some parameters over AJAX, and then let JSF
coordinate what needs to be re-rendered without wasteful marshalling of
unneeded data over the network. Exadel has done a great job of
capturing this type of advancement with their recent offering. JSF 1.2
will help this work even better.
Also, since we are dealing with DHTML/DOM, then you can basically
declare this clientside behavior anywhere and register it with elements
on page load. I think XUL's approach to commands/observers suits this
well as you could even have a plain old HTML controls, but decorate
their events with JSF components which may only 'exist' on the server.
This actually becomes somewhat ideal since other JavaScript could
interact directly with a JSF-agent in the browser to send/coordinate
events with the server.
https://facelets.dev.java.net/source/browse/facelets/demo/avatar/web/?hideattic=0#dirlist
-- Jacob
Craig McClanahan wrote:
On 4/3/06, *Dennis Byrne* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
>Since you never answered the question in your subject line :-), I am
>presuming that POJSO means Plain Old JavaScript Object, right?
Oops, yes. BTW, "POJSO javascript" has no results in google, so
this is hot stuff ;)
/me just burned my fingers on the keyboard :-)
>Given that, JSON has primitives for the Java->JS conversions
(things like
>JSONStringer and JSONWriter) in addition to the primitives for
JS->Java. Is
>what you are after some sort of wrapper around this (that avoids
all the low
>level mechanics to assemble the JSON stream)? That would seem
like a pretty
>nice gadget to have in your toolbox when you have a nice set of POJOs
>modelling the data on the server side already.
Hmmm ... it looks like their license is compatible as well.
http://www.json.org/license.html
>Encapsulating something like this in JSF components would be duck
soup ...
>maybe <t:saveJSON> instead of <t:saveState> :-)
Interesting you mention this, as UISaveState is about 20 lines of
java.
True, but it cheats a bit ... it relies on the fact that POJOs know
how to serialize themselves already. We might be able to mine things
like Commons Betwixt (POJO-->XML) for useful ideas. And, of course,
the underlying functionality should be available via a Java API as
well, to facilitate its use in AJAX event handlers.
>Dennis Byrne
>>
>> Craig
Dennis Byrne
Craig
--
--------------------------
Sent from my FrankenBerry Wireless Handheld
