On Fri, 29 Oct 2004 23:52:49 -0400, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Argh, posted to the wrong list! > > Well, in all honesty, this isn't something that was initiated by me, > I've never had a thought of passing objects back and forth, so I'm not > sure I can give you a real, concrete use case that would explain it. I > certainly hear what your saying about XML. I myself have done that very > thing in place of something like this. > > I think the point that makes this interesting is the idea of objects > end-to-end. Think of it almost like RMI between a browser-based client > and a Java-based back-end. As in RMI, an object gets "flattened" into > some data representation, transmitted and reconstituted on the receiving > end. But on both sides of the conversation you have an object. > > If what your asking is why not just pass XML representing the data > instead of a representation of an object, then I'd say because then you > have to know about some intermediary interpretation of an object, namely > XML. It would kind of be like saying that instead of using RMI, why not > just serialize an object's data as XML and transmit that, then parse it > on the other end... Certainly that's done every day, but RMI is I think > more elegant in that your always dealing in objects, and conversion for > the sake of transport is done transparently.
That is not necessarily true. If you use XML-RPC, specifically one of the several client-side Javascript libraries for XML-RPC, your application, both on the client and server side, never have to touch XML. The XML-RPC library automatically handles serialization/deserialization as does the server side XML-RPC library (Apache has a great one for this). I use XML-RPC in several applications for the specific reason that I never have to deal with XML, yet I get rich communication between my web application and server. Don > > I know what your saying about tying to Javascript, but I'm not sure > there's too many client-side scripting languages to worry about. I > mean, Javascript and VBScript are all I can think of, and although it's > been a while since I worked with VBScript, I don't recall there being an > object creation mechanism like in Javascript, so I'm not sure how big > a concern it is. Certainly I think it's safe to say that Javascript is > by far the most popular client-side scripting language, and therefore a > solution that is going to cover 75% of applications is probably useful. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > Martin Cooper wrote: > > > Just curious, and I'm sure I'm missing something (which is why I'm > > asking!), but why would you want to do this when there are XML based > > solutions there for the using, free, and that don't tie you to > > JavaScript? > > > > Thanks. > > > > -- > > Martin Cooper > > > > > > On Fri, 29 Oct 2004 22:31:32 -0400, Frank W. Zammetti > > <[EMAIL PROTECTED]> wrote: > > > >> On the later idea, I intend to put together a proof-of-concept next week > >> when I get back to the office. I have some family engagements this > >> weekend that will keep me from getting started, and on Tuesday I take > >> the first exam for my SCEA (not to mention the election!), but I have > >> some spare cycles at work currently so I should pretty much have the > >> rest of the week to play. > >> > >> I only mention this because while I obviously can't stop anyone else > >> from beating me to the punch, I do intend to persue this, so if you have > >> any other itches to scratch, go for them, leave this one for me if you > >> would :) > >> > >> -- > >> Frank W. Zammetti > >> Founder and Chief Software Architect > >> Omnytex Technologies > >> http://www.omnytex.com > >> > >> > >> > >> Craig McClanahan wrote: > >> > >>> On Fri, 29 Oct 2004 21:28:52 -0400, Ted Husted <[EMAIL PROTECTED]> > wrote: > >>> > >>> > >>>> That sounds great to me, Don. :) > >>>> > >>>> We already have Struts-Faces and Struts-Examples on the trunk. We > might as well add Struts-BSF and Struts-Flow to the mix. > >>> > >>> > >>> > >>> +1. > >>> > >>> > >>> > >>>> Struts-BSF and Struts-Flow are not part of the core, so they would > be not affected by a 1.2.x branch. > >>>> > >>>> -Ted. > >>>> > >>> > >>> > >>> Note that there have been two overlapping discussions about scripting > >>> on the lists today ... Don's stuff in Struts Flow uses a modified > >>> Rhino (with continutations) to do scripting on the *server* side, > >>> while the earlier conversation about serializing a JavaScript object > >>> and converting it is about scripting on the *client* side, using a > >>> serialized form of JavaScript objects to pass data back and forth > >>> through a hidden field. > >>> > >>> Both ideas are quite cool. > >>> > >>> Craig > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >>> . > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
