[Fwd: Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]

["Frank W. Zammetti" <fz...@omnytex.com>]

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.

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
 > <fz...@omnytex.com> 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 <hu...@apache.org> 
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: dev-unsubscribe@struts.apache.org
 >>> For additional commands, e-mail: dev-help@struts.apache.org
 >>>
 >>>
 >>>
 >>>
 >>> .
 >>>
 >>
 >> ---------------------------------------------------------------------
 >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
 >> For additional commands, e-mail: dev-help@struts.apache.org
 >>
 >>
 >
 >
 >
 >
 >





---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [Fwd: Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]

["Frank W. Zammetti" <fz...@omnytex.com>]

Sorry Struts Users list, this was intended for the Developer's list, I 
clicked the wrong address in my address book.  D'oh!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

Frank W. Zammetti wrote:
> 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.
> 
> 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.
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org