-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Don Brown wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
