You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2004/10/30 05:52:49 UTC
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java
object conversions]]]
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.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java
object conversions]]]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I don't have any resources to offer as all the apps I've done along
these lines have been custom jobs. I have a rather substantial library
that I've built up over the years or client-side functions, widgets and
sich, as probably anyone who's done apps like this has, but none of it
is published anywhere.
I've more or less developed a "framework" for apps like this. It's
nothing really official, but it's a common structure they all kind of
follow. This represents what I'd call a "soft" framework, but I don't
think it's appropriate for many situations anyway. So, I'd say unless
you want to be building everything from scratch, Martin's references are
probably the way to go.
If you do decide to go that route, I would be more than happy to share
whatever experience I have to offer.
Before I forget, about the whole JS-to-Java object conversion thing I
was toying with... it seems people on the list were pointing out some
projects that do this already, and since I couldn't think of any real
value-add (aside maybe from simplicity), I decided to not put much time
into that. I did get it part-way (I was able to generate JS from a Java
object, with some limitations), but I pretty much stopped there. I
don't see the point in doing what has been done already unless I have
something significant to add.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Martin Cooper wrote:
> We are currently using two different frameworks (together). One is
> commercial - Isomorphic SmartClient - and one is open source -
> nWidgets.
>
> SmartClient has a highly sophisticated widget set, and runs on just
> about every browser since Netscape 4.5. They essentially built an API
> layer on top of the browsers, and wrote everything else on top of
> that. Some of their widgets would take huge amounts of work to
> replicate, which is why we use them. ;-) We also use some server-side
> optimisation stuff that comes with SmartClient, and that helped hugely
> with our performance optimisations.
>
> nWidgets is a much smaller, leaner framework that works on top of /
> along side the browser DOM. As such, it doesn't support older
> browsers. The widget set is mediocre, but the underpinnings are very
> powerful, and it's those underpinnings that we use it for. For
> example, it has some really nice mechanisms for partial page refresh
> that we use extensively.
>
> One thing to bear in mind is that SmartClient is huge. They used to
> package it as a single 600KB .js file, which obviously has serious
> startup costs. We are now using a broken down version, where we can
> load only what we need on a give page, but I'm not sure if that made
> it into their product, or is custom for us. (We are probably their
> biggest customer.) nWidgets is much, much smaller.
>
> There are other frameworks out there too. The one to watch is Dojo.
> This is being put together by the brains of all of the high quality
> open source frameworks, with the goal of pooling all of their
> knowledge and coming up with the ultimate in client side frameworks.
> These are a bunch of very smart people. (I know because two of them
> work for us. ;) However, their goals are lofty, and I'm not sure when
> Dojo will be ready for prime time. Other frameworks that I'm aware of,
> but have not used, are Burst and f(m), both of which are open source,
> and FacesClient Components (nee Odyssey Browser Framework) from IBM.
>
> Some links:
>
> http://www.isomorphic.com/index.jsp
> http://nwidgets.org/
> http://www.dojotoolkit.org/
> http://www-106.ibm.com/developerworks/websphere/library/techarticles/0411_hasson/0411_hasson.html
>
> Hope this helps.
>
> --
> Martin Cooper
>
>
> On Wed, 01 Dec 2004 12:27:48 -0500, Mike Kienenberger
> <mk...@alaska.net> wrote:
>
>>Martin and Frank,
>>
>>What resources are available for doing the sort of applications that you're
>>talking about here?
>>
>>Are there any frameworks or books out there that deal with these kinds of
>>approaches? Or is all of this stuff only available in custom apps?
>>
>>I didn't want to post this to struts-dev since, as was stated below, it's
>>"way off topic"
>>
>>My next project is going to involve porting a mainframe GUI customer
>>information system to j2ee application servers, and I don't want to have to
>>reinvent the wheel.
>>
>>Thanks for any pointers you can provide (even google search terms would be
>>appreciated).
>>
>>-Mike
>>
>>
>>
>>
>>Martin Cooper <mf...@gmail.com> wrote:
>>
>>>On Sat, 30 Oct 2004 14:33:12 -0400, Frank W. Zammetti
>>><fz...@omnytex.com> wrote:
>>>
>>>>Martin Cooper wrote:
>>>>
>>>>
>>>>
>>>>>The app you describe does sound a little more extreme than one might
>>>>>want, but I think it's a great illustration of what can be done with
>>>>>JavaScript on the client. The primary app I work on in my day job also
>>>>>uses huge amounts of client side JavaScript to give the user a
>>>>>near-desktop experience. It enables us to provide functionality that
>>>>>just isn't possible with a server side rendering model. Our early
>>>>>attempts at this resulted in pretty horrible performance because of
>>>>>the amount of JavaScript we were downloading, but now that we've tuned
>>>>>things up (caching, compressing, minimizing downloads, etc.),
>>>>>performance is pretty awesome, and orders of magnitude better than
>>>>>where we started.
>>>>
>>>>Sounds like we are very much in the same boat! I agree, the app I was
>>>>referring to IS extreme... I wouldn't do an app to that degree again,
>>>>but it was pretty much forced on me because of the IWT component which I
>>>>had no choice but to use. I didn't have much choice but to do it this
>>
>>way.
>>
>>>>The two major apps I've architected (and mostly coded) subsequent to
>>>>that one are not as extreme as that, but I still use a rather large
>>>>amount of client-side scripting and DOM manipulation. Things like
>>>>sorting of tables, very cool-looking "please wait" screens, popup
>>>>calendars, tailoring of the interface based on user actions, and so on,
>>>>things that as you said just isn't possible with a server side rendering
>>>>model.
>>>
>>>You'd probably enjoy seeing some of the stuff we have. Things like
>>>drag and drop, turning a column into a row and vice versa, hiding and
>>>showing rows and columns, virtual lists and trees, wizards, etc., all
>>>client side.
>>>
>>>
>>>>One of the primary "tricks" I learned with that first app that I've used
>>>>over and over is first of all, frames are your friend, and second of
>>>>all, hidden frames that store things are even MORE your friend. People
>>>>that hate frames I think are afraid of them. It's true that there is
>>>>some added complexity inherent with them, but it tends to be well worth
>>>>it because you get better functionality possible and improved
>>>>performance. Just that fact that you don't have to render the entire UI
>>>>with every request makes it worth it.
>>>
>>>Hidden (i)frames can definitely be a big help, but we've found that
>>>it's best to minimize the actual number of them, because (depending on
>>>the browser) they can chew up a lot of resources. Instead, we have
>>>most of our client-server communication go through one or two hidden
>>>iframes. We also prioritise multiple requests back to the server so
>>>that we can take maximum advantage of the default two connections that
>>>the browser will open simultaneously. Regular frames we don't use at
>>>all - we do that with div elements instead.
>>>
>>>But we're definitely way off topic now... ;-)
>>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>
>>>>A prime example in my most recent app is that a user can switch between
>>>>a number of different clients on-the-fly. When the user first logs on,
>>>>I download into a hidden frame all the pertinent details for all the
>>>>clients and cache them there. It's purely read-only data, so no
>>>>problem. When the user switches clients, I already have everything I
>>>>need, so there's no need to call the server to get all that information
>>>>and make the changes to the interface that are appropriate. Hence,
>>>>performance as perceived by the user (and in truth there's not much
>>>>besides what the user perceives that really matters when it comes to
>>>>performance) is improved over what would otherwise be.
>>>>
>>>>Another cool trick that I actually think I might have been the first
>>>>person to pull off, is a Windows-like dropdown menu across the top that
>>>>actually works across frames. The menu bar itself is a frame, and then
>>>>there's the main portion of the screen below it, which is the only part
>>>>of the UI the server ever renders, the menus are the same once they are
>>>>loaded initially. However, when you click a top-level menu, the
>>>>drop-down appears in the main frame. You can do all the Windows-like
>>>>things with menus, like disabling and enabling (without server
>>>>interaction), you get accelerator keys, icons, etc. None of this is
>>>>unique any more, but I may have been the first to pull it off (if only I
>>>>had published! :) ).
>>>>
>>>>
>>>>>Actually, I don't think this is off-topic at all, given the Shale
>>>>>discussions. I think more people on this list need to be enlightened
>>>>>as to the possibilities of not tying the presentation layer to the
>>>>>server. In particular, I think we need to give careful consideration
>>>>>to the JSF issue, since that framework seems particularly unfriendly
>>>>>to the partial page rendering model.
>>>>
>>>>Well, I think it may have been off-topic with regard to my proposal, but
>>>>I absolutely couldn't agree more... Web developers in general I think
>>>>need to get away from this idea of "the server should do everything".
>>>>The server should do MOST things, but you simply can't get a truly rich,
>>>>high-performance UI with the server-only mindset. At least that's what
>>>>I believe, based on my experience.
>>>>
>>>>
>>>>
>>>>
>>>>>To my knowledge, anyway, JSF is page oriented, relies on a page's
>>>>>component tree for rendering / processing, and does not provide for a
>>>>>client-side component to communicate back to its server-side partner
>>>>>without serialising and deserialising the page tree along with it.
>>>>>That pretty much breaks the partial page rendering scheme right there,
>>>>>unless you have the client and server parts of your components
>>>>>communicate with each other "out of band" as it were, which kinda
>>>>>defeats the purpose of having a component based framework.
>>>>
>>>>I haven't looked at JSF much... I had an introduction to it at a JUG
>>>>recently, and I wasn't overly impressed with what I saw. It seemed like
>>>>an overly complex approach to things that are fairly well-understood
>>>>(and not very complicated) now. There is a natural tendency of
>>>>development to get more complex as time goes by it seems, but the ironic
>>>>part is that it happens as a result of people coming up with things that
>>>>they claim make things simpler and easier! If I have to go and write 10
>>>>different XML config files rather than some relatively simple HTML and
>>>>Javascript, I don't so much care if my IDE can spit out those files for
>>>>me or if I can make changes on-the-fly without touching actual code. At
>>>>some point those config files might as well BE code because it's just
>>>>about as complex, and people that rely on IDEs and tools to generate
>>>>code for them are asking for trouble IMHO, most especially when that's
>>>>ALL they know how to do. JSF struck me as just such a thing, at least
>>>>from the admittedly quick glance I had of it.
>>>>
>>>>But now I really AM getting off-topic :)
>>>>
>>>>--
>>>>Frank W. Zammetti
>>>>Founder and Chief Software Architect
>>>>Omnytex Technologies
>>>>http://www.omnytex.com
>>>>
>>>>
>>>>>--
>>>>>Martin Cooper
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>--
>>>>
>>>>
>>>>>>
>>>>>>Frank W. Zammetti
>>>>>>Founder and Chief Software Architect
>>>>>>Omnytex Technologies
>>>>>>http://www.omnytex.com
>>>>>>
>>>>>>Don Brown wrote:
>>>>>>
>>>>>>
>>>>>>>I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/
>>
>>-
>>
>>>>>>>and have used it successfully in several projects, an ASP application
>>>>>>>and a Struts-based application. I've heard of others, but that one
>>>>>>>has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
>>>>>>>
>>>>>>>This also seems to be a good list of non XML-RPC remote scripting for
>>>>>>>Javascript: http://www.ashleyit.com/rs/main.htm
>>>>>>>
>>>>>>>I've never understood why XML-RPC and remote scripting in general
>>>>>>>haven't been more prevelent in web applications. The main limitation
>>>>>>>is a semi-recent browser, but that shouldn't be an issue in most web
>>>>>>>applications, especially within intranets. The excellent performance
>>>>>>>and developmental simplicity make web applications viable for more
>>>>>>>complex tasks.
>>>>>>>
>>>>>>>Don
>>>>>>>
>>>>>>>
>>>>>>>On Sat, 30 Oct 2004 00:18:08 -0400, Frank W. Zammetti
>>>>>>><fz...@omnytex.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>It sounds like what your saying is that such a beast already
>>
>>exists...
>>
>>>>>>>>I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/,
>>>>>>>>specifically the link to Client Classes... Is this what your
>>
>>referring
>>
>>>>>>>>to? If so, I think this is dealing with writing a Java-based
>>
>>client,
>>
>>>>>>>>not Javascript objects. Assuming that's not it though, can you
>>
>>point me
>>
>>>>>>>>in the right direction? I'm most definitely interested!
>>>>>>>>
>>>>>>>>--
>>>>>>>>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
>>>>>>>>><fz...@omnytex.com> 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
>>>>>>>>>>><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
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]]
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 30 Oct 2004 14:33:12 -0400, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> Martin Cooper wrote:
>
>
> > The app you describe does sound a little more extreme than one might
> > want, but I think it's a great illustration of what can be done with
> > JavaScript on the client. The primary app I work on in my day job also
> > uses huge amounts of client side JavaScript to give the user a
> > near-desktop experience. It enables us to provide functionality that
> > just isn't possible with a server side rendering model. Our early
> > attempts at this resulted in pretty horrible performance because of
> > the amount of JavaScript we were downloading, but now that we've tuned
> > things up (caching, compressing, minimizing downloads, etc.),
> > performance is pretty awesome, and orders of magnitude better than
> > where we started.
>
> Sounds like we are very much in the same boat! I agree, the app I was
> referring to IS extreme... I wouldn't do an app to that degree again,
> but it was pretty much forced on me because of the IWT component which I
> had no choice but to use. I didn't have much choice but to do it this way.
>
> The two major apps I've architected (and mostly coded) subsequent to
> that one are not as extreme as that, but I still use a rather large
> amount of client-side scripting and DOM manipulation. Things like
> sorting of tables, very cool-looking "please wait" screens, popup
> calendars, tailoring of the interface based on user actions, and so on,
> things that as you said just isn't possible with a server side rendering
> model.
You'd probably enjoy seeing some of the stuff we have. Things like
drag and drop, turning a column into a row and vice versa, hiding and
showing rows and columns, virtual lists and trees, wizards, etc., all
client side.
> One of the primary "tricks" I learned with that first app that I've used
> over and over is first of all, frames are your friend, and second of
> all, hidden frames that store things are even MORE your friend. People
> that hate frames I think are afraid of them. It's true that there is
> some added complexity inherent with them, but it tends to be well worth
> it because you get better functionality possible and improved
> performance. Just that fact that you don't have to render the entire UI
> with every request makes it worth it.
Hidden (i)frames can definitely be a big help, but we've found that
it's best to minimize the actual number of them, because (depending on
the browser) they can chew up a lot of resources. Instead, we have
most of our client-server communication go through one or two hidden
iframes. We also prioritise multiple requests back to the server so
that we can take maximum advantage of the default two connections that
the browser will open simultaneously. Regular frames we don't use at
all - we do that with div elements instead.
But we're definitely way off topic now... ;-)
--
Martin Cooper
> A prime example in my most recent app is that a user can switch between
> a number of different clients on-the-fly. When the user first logs on,
> I download into a hidden frame all the pertinent details for all the
> clients and cache them there. It's purely read-only data, so no
> problem. When the user switches clients, I already have everything I
> need, so there's no need to call the server to get all that information
> and make the changes to the interface that are appropriate. Hence,
> performance as perceived by the user (and in truth there's not much
> besides what the user perceives that really matters when it comes to
> performance) is improved over what would otherwise be.
>
> Another cool trick that I actually think I might have been the first
> person to pull off, is a Windows-like dropdown menu across the top that
> actually works across frames. The menu bar itself is a frame, and then
> there's the main portion of the screen below it, which is the only part
> of the UI the server ever renders, the menus are the same once they are
> loaded initially. However, when you click a top-level menu, the
> drop-down appears in the main frame. You can do all the Windows-like
> things with menus, like disabling and enabling (without server
> interaction), you get accelerator keys, icons, etc. None of this is
> unique any more, but I may have been the first to pull it off (if only I
> had published! :) ).
>
> > Actually, I don't think this is off-topic at all, given the Shale
> > discussions. I think more people on this list need to be enlightened
> > as to the possibilities of not tying the presentation layer to the
> > server. In particular, I think we need to give careful consideration
> > to the JSF issue, since that framework seems particularly unfriendly
> > to the partial page rendering model.
>
> Well, I think it may have been off-topic with regard to my proposal, but
> I absolutely couldn't agree more... Web developers in general I think
> need to get away from this idea of "the server should do everything".
> The server should do MOST things, but you simply can't get a truly rich,
> high-performance UI with the server-only mindset. At least that's what
> I believe, based on my experience.
>
>
>
> > To my knowledge, anyway, JSF is page oriented, relies on a page's
> > component tree for rendering / processing, and does not provide for a
> > client-side component to communicate back to its server-side partner
> > without serialising and deserialising the page tree along with it.
> > That pretty much breaks the partial page rendering scheme right there,
> > unless you have the client and server parts of your components
> > communicate with each other "out of band" as it were, which kinda
> > defeats the purpose of having a component based framework.
>
> I haven't looked at JSF much... I had an introduction to it at a JUG
> recently, and I wasn't overly impressed with what I saw. It seemed like
> an overly complex approach to things that are fairly well-understood
> (and not very complicated) now. There is a natural tendency of
> development to get more complex as time goes by it seems, but the ironic
> part is that it happens as a result of people coming up with things that
> they claim make things simpler and easier! If I have to go and write 10
> different XML config files rather than some relatively simple HTML and
> Javascript, I don't so much care if my IDE can spit out those files for
> me or if I can make changes on-the-fly without touching actual code. At
> some point those config files might as well BE code because it's just
> about as complex, and people that rely on IDEs and tools to generate
> code for them are asking for trouble IMHO, most especially when that's
> ALL they know how to do. JSF struck me as just such a thing, at least
> from the admittedly quick glance I had of it.
>
> But now I really AM getting off-topic :)
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> > --
> > Martin Cooper
> >
> >
> >
> >>--
>
>
> >>
> >>
> >>Frank W. Zammetti
> >>Founder and Chief Software Architect
> >>Omnytex Technologies
> >>http://www.omnytex.com
> >>
> >>Don Brown wrote:
> >>
> >>>I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/ -
> >>>and have used it successfully in several projects, an ASP application
> >>>and a Struts-based application. I've heard of others, but that one
> >>>has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
> >>>
> >>>This also seems to be a good list of non XML-RPC remote scripting for
> >>>Javascript: http://www.ashleyit.com/rs/main.htm
> >>>
> >>>I've never understood why XML-RPC and remote scripting in general
> >>>haven't been more prevelent in web applications. The main limitation
> >>>is a semi-recent browser, but that shouldn't be an issue in most web
> >>>applications, especially within intranets. The excellent performance
> >>>and developmental simplicity make web applications viable for more
> >>>complex tasks.
> >>>
> >>>Don
> >>>
> >>>
> >>>On Sat, 30 Oct 2004 00:18:08 -0400, Frank W. Zammetti
> >>><fz...@omnytex.com> wrote:
> >>>
> >>>
> >>>>It sounds like what your saying is that such a beast already exists...
> >>>>I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/,
> >>>>specifically the link to Client Classes... Is this what your referring
> >>>>to? If so, I think this is dealing with writing a Java-based client,
> >>>>not Javascript objects. Assuming that's not it though, can you point me
> >>>>in the right direction? I'm most definitely interested!
> >>>>
> >>>>--
> >>>>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
> >>>>><fz...@omnytex.com> 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
> >>>>>>><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: 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: 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: 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: 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
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java
object conversions]]]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> The app you describe does sound a little more extreme than one might
> want, but I think it's a great illustration of what can be done with
> JavaScript on the client. The primary app I work on in my day job also
> uses huge amounts of client side JavaScript to give the user a
> near-desktop experience. It enables us to provide functionality that
> just isn't possible with a server side rendering model. Our early
> attempts at this resulted in pretty horrible performance because of
> the amount of JavaScript we were downloading, but now that we've tuned
> things up (caching, compressing, minimizing downloads, etc.),
> performance is pretty awesome, and orders of magnitude better than
> where we started.
Sounds like we are very much in the same boat! I agree, the app I was
referring to IS extreme... I wouldn't do an app to that degree again,
but it was pretty much forced on me because of the IWT component which I
had no choice but to use. I didn't have much choice but to do it this way.
The two major apps I've architected (and mostly coded) subsequent to
that one are not as extreme as that, but I still use a rather large
amount of client-side scripting and DOM manipulation. Things like
sorting of tables, very cool-looking "please wait" screens, popup
calendars, tailoring of the interface based on user actions, and so on,
things that as you said just isn't possible with a server side rendering
model.
One of the primary "tricks" I learned with that first app that I've used
over and over is first of all, frames are your friend, and second of
all, hidden frames that store things are even MORE your friend. People
that hate frames I think are afraid of them. It's true that there is
some added complexity inherent with them, but it tends to be well worth
it because you get better functionality possible and improved
performance. Just that fact that you don't have to render the entire UI
with every request makes it worth it.
A prime example in my most recent app is that a user can switch between
a number of different clients on-the-fly. When the user first logs on,
I download into a hidden frame all the pertinent details for all the
clients and cache them there. It's purely read-only data, so no
problem. When the user switches clients, I already have everything I
need, so there's no need to call the server to get all that information
and make the changes to the interface that are appropriate. Hence,
performance as perceived by the user (and in truth there's not much
besides what the user perceives that really matters when it comes to
performance) is improved over what would otherwise be.
Another cool trick that I actually think I might have been the first
person to pull off, is a Windows-like dropdown menu across the top that
actually works across frames. The menu bar itself is a frame, and then
there's the main portion of the screen below it, which is the only part
of the UI the server ever renders, the menus are the same once they are
loaded initially. However, when you click a top-level menu, the
drop-down appears in the main frame. You can do all the Windows-like
things with menus, like disabling and enabling (without server
interaction), you get accelerator keys, icons, etc. None of this is
unique any more, but I may have been the first to pull it off (if only I
had published! :) ).
> Actually, I don't think this is off-topic at all, given the Shale
> discussions. I think more people on this list need to be enlightened
> as to the possibilities of not tying the presentation layer to the
> server. In particular, I think we need to give careful consideration
> to the JSF issue, since that framework seems particularly unfriendly
> to the partial page rendering model.
Well, I think it may have been off-topic with regard to my proposal, but
I absolutely couldn't agree more... Web developers in general I think
need to get away from this idea of "the server should do everything".
The server should do MOST things, but you simply can't get a truly rich,
high-performance UI with the server-only mindset. At least that's what
I believe, based on my experience.
> To my knowledge, anyway, JSF is page oriented, relies on a page's
> component tree for rendering / processing, and does not provide for a
> client-side component to communicate back to its server-side partner
> without serialising and deserialising the page tree along with it.
> That pretty much breaks the partial page rendering scheme right there,
> unless you have the client and server parts of your components
> communicate with each other "out of band" as it were, which kinda
> defeats the purpose of having a component based framework.
I haven't looked at JSF much... I had an introduction to it at a JUG
recently, and I wasn't overly impressed with what I saw. It seemed like
an overly complex approach to things that are fairly well-understood
(and not very complicated) now. There is a natural tendency of
development to get more complex as time goes by it seems, but the ironic
part is that it happens as a result of people coming up with things that
they claim make things simpler and easier! If I have to go and write 10
different XML config files rather than some relatively simple HTML and
Javascript, I don't so much care if my IDE can spit out those files for
me or if I can make changes on-the-fly without touching actual code. At
some point those config files might as well BE code because it's just
about as complex, and people that rely on IDEs and tools to generate
code for them are asking for trouble IMHO, most especially when that's
ALL they know how to do. JSF struck me as just such a thing, at least
from the admittedly quick glance I had of it.
But now I really AM getting off-topic :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
> --
> Martin Cooper
>
>
>
>>--
>>
>>
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>Don Brown wrote:
>>
>>>I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/ -
>>>and have used it successfully in several projects, an ASP application
>>>and a Struts-based application. I've heard of others, but that one
>>>has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
>>>
>>>This also seems to be a good list of non XML-RPC remote scripting for
>>>Javascript: http://www.ashleyit.com/rs/main.htm
>>>
>>>I've never understood why XML-RPC and remote scripting in general
>>>haven't been more prevelent in web applications. The main limitation
>>>is a semi-recent browser, but that shouldn't be an issue in most web
>>>applications, especially within intranets. The excellent performance
>>>and developmental simplicity make web applications viable for more
>>>complex tasks.
>>>
>>>Don
>>>
>>>
>>>On Sat, 30 Oct 2004 00:18:08 -0400, Frank W. Zammetti
>>><fz...@omnytex.com> wrote:
>>>
>>>
>>>>It sounds like what your saying is that such a beast already exists...
>>>>I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/,
>>>>specifically the link to Client Classes... Is this what your referring
>>>>to? If so, I think this is dealing with writing a Java-based client,
>>>>not Javascript objects. Assuming that's not it though, can you point me
>>>>in the right direction? I'm most definitely interested!
>>>>
>>>>--
>>>>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
>>>>><fz...@omnytex.com> 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
>>>>>>><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: 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: 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: 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 2 Nov 2004 21:43:41 -0800, Martin Cooper <mf...@gmail.com> wrote:
> This is a really interesting statement. Perhaps I'm wrong, but I've
> always thought the whole point of JSF was visual components. Yet the
> statement above clearly indicates that JSF goes well beyond that
> charter, and clearly suggests that there are facets of JSF that should
> not be a part of that JSR.
FWIW, here is IBM's take on how to build rich web applications using
JSF components plus a framework for sending data back and forth:
http://www-106.ibm.com/developerworks/websphere/library/techarticles/0411_hasson/0411_hasson.html?ca=dnp-344
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
Posted by Craig McClanahan <cr...@gmail.com>.
In order to meet the spec requirements for handling server side events
related to the view tier components, JSF also provides a front
controller responsible for handling the server side request processing
lifecycle, with event listeners and other plug-in points for either
application code or controller-level frameworks (like something that
would manage a wizard dialog). Without such functionality, JSF would
have been useless without an application framework to provide the
lifecycle services ... and, if everyone invents their own lifecycle,
you'd end up with JSF components that were specific to a particular
controller even though they conform to a common component API. That
would have been fairly useless.
Shale proposes to leverage the extension points of this front
controller instead of reinventing it yet again -- the world doesn't
need YAWAF (yet another web application framework) that doesn't do
anything new. It needs something that makes developing web
applications in Java easier for non-rocket scientists.
Craig
On Wed, 3 Nov 2004 09:05:54 -0600, Michael Rasmussen
<ra...@gmail.com> wrote:
> > statement above clearly indicates that JSF goes well beyond that
> > charter, and clearly suggests that there are facets of JSF that should
> > not be a part of that JSR.
> >
> From the original design goals of JSR 127 (JSF)
> "Provide a JavaBeans model for dispatching events from client-side
> GUI controls to server-side application behavior."
>
> I read this as "Actions" in struts.
>
>
> > Shale purports to depend on the parts of JSF that are unrelated to
> > visual components, while visual components are the "raison d'etre" for
> > JSF. So what, exactly, is the connection between JSF and Shale?
>
>
> I could be totally wrong but I think the idea is to depend on these
> classes to create the backbone for things like actions in struts
> shale, using the ViewController as a JSF Managed Bean for event
> handling in the controller. Craig?
>
>
>
> > And why does Shale need to be linked to JSF?
> >
> > --
> > Martin Cooper
> >
> >
> >
> >
> > > 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: 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
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
Posted by Michael Rasmussen <ra...@gmail.com>.
> statement above clearly indicates that JSF goes well beyond that
> charter, and clearly suggests that there are facets of JSF that should
> not be a part of that JSR.
>
>From the original design goals of JSR 127 (JSF)
"Provide a JavaBeans model for dispatching events from client-side
GUI controls to server-side application behavior."
I read this as "Actions" in struts.
> Shale purports to depend on the parts of JSF that are unrelated to
> visual components, while visual components are the "raison d'etre" for
> JSF. So what, exactly, is the connection between JSF and Shale?
I could be totally wrong but I think the idea is to depend on these
classes to create the backbone for things like actions in struts
shale, using the ViewController as a JSF Managed Bean for event
handling in the controller. Craig?
> And why does Shale need to be linked to JSF?
>
> --
> Martin Cooper
>
>
>
>
> > 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
Posted by Martin Cooper <mf...@gmail.com>.
On Sun, 31 Oct 2004 23:00:41 -0700, Craig McClanahan <cr...@gmail.com> wrote:
> On Sun, 31 Oct 2004 21:30:22 -0600, Eddie Bush <ea...@swbell.net> wrote:
> >
> > Unless Martin is incorrect about the way JSF handles requests, I'm inclined
> > to believe (despite the fact JSF will be a part of the next specification)
> > we might want to consider using something else under the covers in our next
> > major "era of Struts". I love the idea of adherance to specifications,
> > don't get me wrong ... so long as it is pragmatic to do so.
>
> Repeat after me ... "the parts of JSF that Shale proposes to depend on
> have NOTHING to do with visual components ...".
This is a really interesting statement. Perhaps I'm wrong, but I've
always thought the whole point of JSF was visual components. Yet the
statement above clearly indicates that JSF goes well beyond that
charter, and clearly suggests that there are facets of JSF that should
not be a part of that JSR.
Shale purports to depend on the parts of JSF that are unrelated to
visual components, while visual components are the "raison d'etre" for
JSF. So what, exactly, is the connection between JSF and Shale?
And why does Shale need to be linked to JSF?
--
Martin Cooper
> 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
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 31 Oct 2004 21:30:22 -0600, Eddie Bush <ea...@swbell.net> wrote:
>
> Unless Martin is incorrect about the way JSF handles requests, I'm inclined
> to believe (despite the fact JSF will be a part of the next specification)
> we might want to consider using something else under the covers in our next
> major "era of Struts". I love the idea of adherance to specifications,
> don't get me wrong ... so long as it is pragmatic to do so.
Repeat after me ... "the parts of JSF that Shale proposes to depend on
have NOTHING to do with visual components ...". Thus, any arguments
over whether JSF adequately helps you build rich web interfaces (it
doesn't yet -- that was out of scope for 1.0) are not relevant to the
Shale decision.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
Posted by Eddie Bush <ea...@swbell.net>.
I haven't found much need to utilize scriplets since the JSTL came along.
Indeed, I feel pages are much cleaner and a great deal more legible if
taglibs are used. I rarely, if ever, use anything except the JSTL though.
One notable exception is Struts' own taglibs. I make other exceptions from
time to time, but there's got to be significant justification for doing so
:-)
I echo Martin's sentiment on the assignment of responsibilities too though.
In fact, within the organization I work for, we actually act as support for
our own applications. There is a level-1 support tier, but all they really
do is log tickets that we handle.
Unless Martin is incorrect about the way JSF handles requests, I'm inclined
to believe (despite the fact JSF will be a part of the next specification)
we might want to consider using something else under the covers in our next
major "era of Struts". I love the idea of adherance to specifications,
don't get me wrong ... so long as it is pragmatic to do so.
Kind Regards,
Eddie Bush
----- Original Message -----
From: "Frank W. Zammetti" <fz...@omnytex.com>
To: "Struts Developers List" <de...@struts.apache.org>
Cc: <cr...@apache.org>
Sent: Sunday, October 31, 2004 7:03 PM
Subject: Re: JSF and highly dynamic apps (was Re: Struts-BSF,
Struts-Scripting [was Re: Proposal: Javascript-to-Java object
conversions]]])
> Martin, you make an interesting comment that I think ties into this
> discussion (loosely ;) ) that is worth mentioning...
>
> A lot of the tools us architects and developers use these days really only
> make sense in cases where you have a separation of activities in terms of
> page authors and developers. I echo your experience in that no
> organization I've ever worked in has had this separation. I know that
> such places exist, but my experience (and having talked to others) leads
> me to believe they are not the usual state of things.
>
> I personally have a dislike of taglibs in general. It's not that I won't
> use them and it's not that I don't recognize the benefit in some cases,
> but I truly believe that we use them way too much. If your in one of
> those organizations where you have page developers vs. back-end
> developers, then taglibs make total sense. In the types of organizations
> you and I seem to have had experience in though, they don't really buy you
> as much as some claim.
>
> In fact, I think they hinder you many times. I mean, if I write scriplets
> (assuming I do so in a resonably clear way and try and minimize it as much
> as possible), I find that to be easier to understand that having to go off
> and look at some tag handler source code. All the code in one place,
> namely the JSP, in other words.
>
> JSF struck me in the same way... It didn't seem that the added complexity
> was going to buy me much, if anything.
>
> My point, which I think I made before in this thread, is simply that a lot
> of the relatively recent developments that are billed as making our lives
> so much easier and less complex in fact do just the opposite. Rather than
> constantly trying to reinvent or improve upon the wheel, people should
> spend more time understanding what capabilities they already have without
> adding all the outside stuff.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
> Martin Cooper wrote:
>> I hear what you're saying, Craig. However, I still feel that JSF
>> doesn't buy me much when building highly dynamic apps. Some points to
>> consider:
>>
>> * Since one of the goals of such apps is to minimise the number of
>> full page refreshes, relatively little of the app can be constructed
>> using tools such as Java Studio Creator. For example, if I need a
>> tabbed pane where working within the tabs and switching between tabs
>> do not cause page refreshes, then JSF might help me put that component
>> on the page initially, but it does nothing for me with respect to user
>> interaction with that pane. The latter is the bulk of my development
>> effort, not the initial page layout.
>>
>> * As you mentioned, partial page refresh functionality is going to
>> require a back channel that to some extent replaces what JSF would
>> give me if I used a full page refresh scheme instead. This distinctly
>> lessens the value of JSF to me, when much of my app is going to need
>> to use this back channel, and so cannot take advantage of JSF.
>>
>> * The types of components I need in my apps today do not exist. So in
>> order to use JSF tools, I have to build all my own JSF components
>> first. Given how little of my development is going to be spent on
>> initial page creation, that seems like a lot of work for not much
>> value.
>>
>> * We don't have the concept of page authors as distinct from
>> developers. We have user interaction designers, but they're not the
>> kind of people who would use a tool like Creator. In fact, no company
>> I've worked at has those types of people, and I've seen many people
>> say the same thing on the Struts lists over the years. I don't doubt
>> that they exist - I just have not personally encountered them, and
>> obviously I'm not alone. ;-)
>>
>> Combine the above with the comments I've seen from people like Hans
>> Bergsten and Adam Winer - both EG members - regarding the issues with
>> using JSF in JSP pages, and JSF really doesn't look attractive to me
>> right now. (Hans's comments are here
>> http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html and I saw a
>> similar comment from Adam about the need for custom view handlers in a
>> mail message somewhere. I don't have that reference handy right now.)
>>
>> I actually want to be wrong about this. ;-) I would really like to be
>> able to use a standard framework like JSF to build my apps, rather
>> than having to do my own thing. However, I'm just not seeing how JSF
>> would give me enough of a benefit to make it worth the cost.
>>
>> Just to be clear, I'm certainly not saying that JSF has no value. I do
>> see that, if the components are there to use, and you're not building
>> a highly dynamic app (or, if you are, you also have a lot of distinct
>> pages to construct and a page designer person doing that), JSF would
>> help you get there faster. Unfortunately, that's not the case for me,
>> and probably for many people building next generation web apps.
>>
>> --
>> Martin Cooper
>>
>>
>>
>> On Sat, 30 Oct 2004 14:54:16 -0700, Craig McClanahan <cr...@gmail.com>
>> wrote:
>>
>>>On Sat, 30 Oct 2004 11:03:29 -0700, Martin Cooper <mf...@gmail.com>
>>>wrote:
>>>
>>>
>>>
>>>>To my knowledge, anyway, JSF is page oriented, relies on a page's
>>>>component tree for rendering / processing, and does not provide for a
>>>>client-side component to communicate back to its server-side partner
>>>>without serialising and deserialising the page tree along with it.
>>>>That pretty much breaks the partial page rendering scheme right there,
>>>>unless you have the client and server parts of your components
>>>>communicate with each other "out of band" as it were, which kinda
>>>>defeats the purpose of having a component based framework.
>>>
>>>There's more than one purpose for a server side component based
>>>framework, and more than one way to deal with client side scripting.
>>>
>>>One of the most important features of components on the server side is
>>>so that tools can know enough about a component that it's possible to
>>>create a high quality user experience at design time. For instance,
>>>when a page author manipulates a tool on a graphical design surface
>>>(as in Sun Java Studio Creator, for example), the tool has to know
>>>what properties are available, what the legal values for each property
>>>are (or, alternatively, provide type-specific property editors for
>>>complex things), and ... among other things ... how to persist the
>>>user's choice in code (either as attributes of a JSP tag, or
>>>initializations in an XML file, or perhaps some generated Java code in
>>>a backing bean class). JSF provides sufficient infrastructure to make
>>>this fairly straightforward.
>>>
>>>The standard JSF components don't do anything particular in terms of
>>>client side scripting (with minor exceptions). That doesn't mean a
>>>component can't do so -- it just means that (for JSF 1.0/1.1 at least)
>>>JSF doesn't provide you any particular help.
>>>
>>>It's pretty straightforward to think about some sort of a "panel"
>>>component that does layout management, with "label" and "field"
>>>components you can drop on it -- and some more complicated things ike
>>>a "tree control" or a "sortable table" that you can use to display
>>>volumes of data in interesting ways. It's also pretty easy to imagine
>>>a server side implementation of these sorts of components (the
>>>standard ones that come with JSF get you most of the way) that depend
>>>on a complete page refresh. But that's by no means the only thing
>>>that is possible.
>>>
>>>Switch your JSF renderers to something smarter and those same
>>>components can be used to render a description (in XML or JS objects
>>>or whatever you like) of what the panel should look like, along with
>>>its constituent parts, and pass that off to the client for actual
>>>processing. While you're at it, provide (inside your component
>>>definitions) a way to do back channel communication to the server so
>>>that the "submit button" doesn't really do that -- instead it
>>>marshalls all or part of your data and waits for incremental updates
>>>coming back. And, if you want to get fancier, make the scrolling
>>>controls on your tree control ask for the next or previous page's
>>>worth of data via the back channel, instead of rerendering the entire
>>>page.
>>>
>>>For JavaOne 2003, we built a primitive version of this for a demo that
>>>used SVG as a client side rendering technology -- the renderers just
>>>created an XML abstraction representing the page and sent that off to
>>>the client, where it was converted into actual SVG markup that was
>>>then executed. The test application was the standard "car demo" app
>>>that comes with the JSF RI -- we kept the components and the back end
>>>logic, but benefitted from cool stuff that SVG enabled on the client
>>>side. We didn't go as far as the back channel communication step, but
>>>there's prior art for how to do that, which JSF components can take
>>>advantage of.
>>>
>>>The key is that I can use a tool to build that application, or even
>>>code the tags into a JSP page by hand, and get *either* kind of
>>>support. JSF (in the current generation) doesn't provide you any API
>>>support for the client side components or the communications channel
>>>-- but it provides you a very easy way to capture the design intent of
>>>the page author, hiding the complexitly of the communications channel
>>>inside the renderers where it belongs.
>>>
>>>It's feasible to use technologies that require your page authors to be
>>>intimately familiar with serializing Javascript objects, or parsing
>>>XML, and so on -- but that limits the potential audience to those that
>>>have the technical skills to understand them. On the other hand, I've
>>>seen a demo of a JSF tree control whose backing tree had several
>>>thousands of elements in it, which did exactly the partial refresh
>>>trick (dynamically grabbing data as needed when you expand a node) --
>>>but you'd never know it from looking at the couple of simple tags in
>>>the JSP page.
>>>
>>>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
>
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0444-3, 10/29/2004
Tested on: 10/31/2004 9:30:25 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting
[was Re: Proposal: Javascript-to-Java object conversions]]])
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin, you make an interesting comment that I think ties into this
discussion (loosely ;) ) that is worth mentioning...
A lot of the tools us architects and developers use these days really
only make sense in cases where you have a separation of activities in
terms of page authors and developers. I echo your experience in that no
organization I've ever worked in has had this separation. I know that
such places exist, but my experience (and having talked to others) leads
me to believe they are not the usual state of things.
I personally have a dislike of taglibs in general. It's not that I
won't use them and it's not that I don't recognize the benefit in some
cases, but I truly believe that we use them way too much. If your in
one of those organizations where you have page developers vs. back-end
developers, then taglibs make total sense. In the types of
organizations you and I seem to have had experience in though, they
don't really buy you as much as some claim.
In fact, I think they hinder you many times. I mean, if I write
scriplets (assuming I do so in a resonably clear way and try and
minimize it as much as possible), I find that to be easier to understand
that having to go off and look at some tag handler source code. All the
code in one place, namely the JSP, in other words.
JSF struck me in the same way... It didn't seem that the added
complexity was going to buy me much, if anything.
My point, which I think I made before in this thread, is simply that a
lot of the relatively recent developments that are billed as making our
lives so much easier and less complex in fact do just the opposite.
Rather than constantly trying to reinvent or improve upon the wheel,
people should spend more time understanding what capabilities they
already have without adding all the outside stuff.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Martin Cooper wrote:
> I hear what you're saying, Craig. However, I still feel that JSF
> doesn't buy me much when building highly dynamic apps. Some points to
> consider:
>
> * Since one of the goals of such apps is to minimise the number of
> full page refreshes, relatively little of the app can be constructed
> using tools such as Java Studio Creator. For example, if I need a
> tabbed pane where working within the tabs and switching between tabs
> do not cause page refreshes, then JSF might help me put that component
> on the page initially, but it does nothing for me with respect to user
> interaction with that pane. The latter is the bulk of my development
> effort, not the initial page layout.
>
> * As you mentioned, partial page refresh functionality is going to
> require a back channel that to some extent replaces what JSF would
> give me if I used a full page refresh scheme instead. This distinctly
> lessens the value of JSF to me, when much of my app is going to need
> to use this back channel, and so cannot take advantage of JSF.
>
> * The types of components I need in my apps today do not exist. So in
> order to use JSF tools, I have to build all my own JSF components
> first. Given how little of my development is going to be spent on
> initial page creation, that seems like a lot of work for not much
> value.
>
> * We don't have the concept of page authors as distinct from
> developers. We have user interaction designers, but they're not the
> kind of people who would use a tool like Creator. In fact, no company
> I've worked at has those types of people, and I've seen many people
> say the same thing on the Struts lists over the years. I don't doubt
> that they exist - I just have not personally encountered them, and
> obviously I'm not alone. ;-)
>
> Combine the above with the comments I've seen from people like Hans
> Bergsten and Adam Winer - both EG members - regarding the issues with
> using JSF in JSP pages, and JSF really doesn't look attractive to me
> right now. (Hans's comments are here
> http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html and I saw a
> similar comment from Adam about the need for custom view handlers in a
> mail message somewhere. I don't have that reference handy right now.)
>
> I actually want to be wrong about this. ;-) I would really like to be
> able to use a standard framework like JSF to build my apps, rather
> than having to do my own thing. However, I'm just not seeing how JSF
> would give me enough of a benefit to make it worth the cost.
>
> Just to be clear, I'm certainly not saying that JSF has no value. I do
> see that, if the components are there to use, and you're not building
> a highly dynamic app (or, if you are, you also have a lot of distinct
> pages to construct and a page designer person doing that), JSF would
> help you get there faster. Unfortunately, that's not the case for me,
> and probably for many people building next generation web apps.
>
> --
> Martin Cooper
>
>
>
> On Sat, 30 Oct 2004 14:54:16 -0700, Craig McClanahan <cr...@gmail.com> wrote:
>
>>On Sat, 30 Oct 2004 11:03:29 -0700, Martin Cooper <mf...@gmail.com> wrote:
>>
>>
>>
>>>To my knowledge, anyway, JSF is page oriented, relies on a page's
>>>component tree for rendering / processing, and does not provide for a
>>>client-side component to communicate back to its server-side partner
>>>without serialising and deserialising the page tree along with it.
>>>That pretty much breaks the partial page rendering scheme right there,
>>>unless you have the client and server parts of your components
>>>communicate with each other "out of band" as it were, which kinda
>>>defeats the purpose of having a component based framework.
>>
>>There's more than one purpose for a server side component based
>>framework, and more than one way to deal with client side scripting.
>>
>>One of the most important features of components on the server side is
>>so that tools can know enough about a component that it's possible to
>>create a high quality user experience at design time. For instance,
>>when a page author manipulates a tool on a graphical design surface
>>(as in Sun Java Studio Creator, for example), the tool has to know
>>what properties are available, what the legal values for each property
>>are (or, alternatively, provide type-specific property editors for
>>complex things), and ... among other things ... how to persist the
>>user's choice in code (either as attributes of a JSP tag, or
>>initializations in an XML file, or perhaps some generated Java code in
>>a backing bean class). JSF provides sufficient infrastructure to make
>>this fairly straightforward.
>>
>>The standard JSF components don't do anything particular in terms of
>>client side scripting (with minor exceptions). That doesn't mean a
>>component can't do so -- it just means that (for JSF 1.0/1.1 at least)
>>JSF doesn't provide you any particular help.
>>
>>It's pretty straightforward to think about some sort of a "panel"
>>component that does layout management, with "label" and "field"
>>components you can drop on it -- and some more complicated things ike
>>a "tree control" or a "sortable table" that you can use to display
>>volumes of data in interesting ways. It's also pretty easy to imagine
>>a server side implementation of these sorts of components (the
>>standard ones that come with JSF get you most of the way) that depend
>>on a complete page refresh. But that's by no means the only thing
>>that is possible.
>>
>>Switch your JSF renderers to something smarter and those same
>>components can be used to render a description (in XML or JS objects
>>or whatever you like) of what the panel should look like, along with
>>its constituent parts, and pass that off to the client for actual
>>processing. While you're at it, provide (inside your component
>>definitions) a way to do back channel communication to the server so
>>that the "submit button" doesn't really do that -- instead it
>>marshalls all or part of your data and waits for incremental updates
>>coming back. And, if you want to get fancier, make the scrolling
>>controls on your tree control ask for the next or previous page's
>>worth of data via the back channel, instead of rerendering the entire
>>page.
>>
>>For JavaOne 2003, we built a primitive version of this for a demo that
>>used SVG as a client side rendering technology -- the renderers just
>>created an XML abstraction representing the page and sent that off to
>>the client, where it was converted into actual SVG markup that was
>>then executed. The test application was the standard "car demo" app
>>that comes with the JSF RI -- we kept the components and the back end
>>logic, but benefitted from cool stuff that SVG enabled on the client
>>side. We didn't go as far as the back channel communication step, but
>>there's prior art for how to do that, which JSF components can take
>>advantage of.
>>
>>The key is that I can use a tool to build that application, or even
>>code the tags into a JSP page by hand, and get *either* kind of
>>support. JSF (in the current generation) doesn't provide you any API
>>support for the client side components or the communications channel
>>-- but it provides you a very easy way to capture the design intent of
>>the page author, hiding the complexitly of the communications channel
>>inside the renderers where it belongs.
>>
>>It's feasible to use technologies that require your page authors to be
>>intimately familiar with serializing Javascript objects, or parsing
>>XML, and so on -- but that limits the potential audience to those that
>>have the technical skills to understand them. On the other hand, I've
>>seen a demo of a JSF tree control whose backing tree had several
>>thousands of elements in it, which did exactly the partial refresh
>>trick (dynamically grabbing data as needed when you expand a node) --
>>but you'd never know it from looking at the couple of simple tags in
>>the JSP page.
>>
>>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
JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
Posted by Martin Cooper <mf...@gmail.com>.
I hear what you're saying, Craig. However, I still feel that JSF
doesn't buy me much when building highly dynamic apps. Some points to
consider:
* Since one of the goals of such apps is to minimise the number of
full page refreshes, relatively little of the app can be constructed
using tools such as Java Studio Creator. For example, if I need a
tabbed pane where working within the tabs and switching between tabs
do not cause page refreshes, then JSF might help me put that component
on the page initially, but it does nothing for me with respect to user
interaction with that pane. The latter is the bulk of my development
effort, not the initial page layout.
* As you mentioned, partial page refresh functionality is going to
require a back channel that to some extent replaces what JSF would
give me if I used a full page refresh scheme instead. This distinctly
lessens the value of JSF to me, when much of my app is going to need
to use this back channel, and so cannot take advantage of JSF.
* The types of components I need in my apps today do not exist. So in
order to use JSF tools, I have to build all my own JSF components
first. Given how little of my development is going to be spent on
initial page creation, that seems like a lot of work for not much
value.
* We don't have the concept of page authors as distinct from
developers. We have user interaction designers, but they're not the
kind of people who would use a tool like Creator. In fact, no company
I've worked at has those types of people, and I've seen many people
say the same thing on the Struts lists over the years. I don't doubt
that they exist - I just have not personally encountered them, and
obviously I'm not alone. ;-)
Combine the above with the comments I've seen from people like Hans
Bergsten and Adam Winer - both EG members - regarding the issues with
using JSF in JSP pages, and JSF really doesn't look attractive to me
right now. (Hans's comments are here
http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html and I saw a
similar comment from Adam about the need for custom view handlers in a
mail message somewhere. I don't have that reference handy right now.)
I actually want to be wrong about this. ;-) I would really like to be
able to use a standard framework like JSF to build my apps, rather
than having to do my own thing. However, I'm just not seeing how JSF
would give me enough of a benefit to make it worth the cost.
Just to be clear, I'm certainly not saying that JSF has no value. I do
see that, if the components are there to use, and you're not building
a highly dynamic app (or, if you are, you also have a lot of distinct
pages to construct and a page designer person doing that), JSF would
help you get there faster. Unfortunately, that's not the case for me,
and probably for many people building next generation web apps.
--
Martin Cooper
On Sat, 30 Oct 2004 14:54:16 -0700, Craig McClanahan <cr...@gmail.com> wrote:
> On Sat, 30 Oct 2004 11:03:29 -0700, Martin Cooper <mf...@gmail.com> wrote:
>
>
> > To my knowledge, anyway, JSF is page oriented, relies on a page's
> > component tree for rendering / processing, and does not provide for a
> > client-side component to communicate back to its server-side partner
> > without serialising and deserialising the page tree along with it.
> > That pretty much breaks the partial page rendering scheme right there,
> > unless you have the client and server parts of your components
> > communicate with each other "out of band" as it were, which kinda
> > defeats the purpose of having a component based framework.
>
> There's more than one purpose for a server side component based
> framework, and more than one way to deal with client side scripting.
>
> One of the most important features of components on the server side is
> so that tools can know enough about a component that it's possible to
> create a high quality user experience at design time. For instance,
> when a page author manipulates a tool on a graphical design surface
> (as in Sun Java Studio Creator, for example), the tool has to know
> what properties are available, what the legal values for each property
> are (or, alternatively, provide type-specific property editors for
> complex things), and ... among other things ... how to persist the
> user's choice in code (either as attributes of a JSP tag, or
> initializations in an XML file, or perhaps some generated Java code in
> a backing bean class). JSF provides sufficient infrastructure to make
> this fairly straightforward.
>
> The standard JSF components don't do anything particular in terms of
> client side scripting (with minor exceptions). That doesn't mean a
> component can't do so -- it just means that (for JSF 1.0/1.1 at least)
> JSF doesn't provide you any particular help.
>
> It's pretty straightforward to think about some sort of a "panel"
> component that does layout management, with "label" and "field"
> components you can drop on it -- and some more complicated things ike
> a "tree control" or a "sortable table" that you can use to display
> volumes of data in interesting ways. It's also pretty easy to imagine
> a server side implementation of these sorts of components (the
> standard ones that come with JSF get you most of the way) that depend
> on a complete page refresh. But that's by no means the only thing
> that is possible.
>
> Switch your JSF renderers to something smarter and those same
> components can be used to render a description (in XML or JS objects
> or whatever you like) of what the panel should look like, along with
> its constituent parts, and pass that off to the client for actual
> processing. While you're at it, provide (inside your component
> definitions) a way to do back channel communication to the server so
> that the "submit button" doesn't really do that -- instead it
> marshalls all or part of your data and waits for incremental updates
> coming back. And, if you want to get fancier, make the scrolling
> controls on your tree control ask for the next or previous page's
> worth of data via the back channel, instead of rerendering the entire
> page.
>
> For JavaOne 2003, we built a primitive version of this for a demo that
> used SVG as a client side rendering technology -- the renderers just
> created an XML abstraction representing the page and sent that off to
> the client, where it was converted into actual SVG markup that was
> then executed. The test application was the standard "car demo" app
> that comes with the JSF RI -- we kept the components and the back end
> logic, but benefitted from cool stuff that SVG enabled on the client
> side. We didn't go as far as the back channel communication step, but
> there's prior art for how to do that, which JSF components can take
> advantage of.
>
> The key is that I can use a tool to build that application, or even
> code the tags into a JSP page by hand, and get *either* kind of
> support. JSF (in the current generation) doesn't provide you any API
> support for the client side components or the communications channel
> -- but it provides you a very easy way to capture the design intent of
> the page author, hiding the complexitly of the communications channel
> inside the renderers where it belongs.
>
> It's feasible to use technologies that require your page authors to be
> intimately familiar with serializing Javascript objects, or parsing
> XML, and so on -- but that limits the potential audience to those that
> have the technical skills to understand them. On the other hand, I've
> seen a demo of a JSF tree control whose backing tree had several
> thousands of elements in it, which did exactly the partial refresh
> trick (dynamically grabbing data as needed when you expand a node) --
> but you'd never know it from looking at the couple of simple tags in
> the JSP page.
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]]
Posted by Craig McClanahan <cr...@gmail.com>.
On Sat, 30 Oct 2004 11:03:29 -0700, Martin Cooper <mf...@gmail.com> wrote:
> To my knowledge, anyway, JSF is page oriented, relies on a page's
> component tree for rendering / processing, and does not provide for a
> client-side component to communicate back to its server-side partner
> without serialising and deserialising the page tree along with it.
> That pretty much breaks the partial page rendering scheme right there,
> unless you have the client and server parts of your components
> communicate with each other "out of band" as it were, which kinda
> defeats the purpose of having a component based framework.
There's more than one purpose for a server side component based
framework, and more than one way to deal with client side scripting.
One of the most important features of components on the server side is
so that tools can know enough about a component that it's possible to
create a high quality user experience at design time. For instance,
when a page author manipulates a tool on a graphical design surface
(as in Sun Java Studio Creator, for example), the tool has to know
what properties are available, what the legal values for each property
are (or, alternatively, provide type-specific property editors for
complex things), and ... among other things ... how to persist the
user's choice in code (either as attributes of a JSP tag, or
initializations in an XML file, or perhaps some generated Java code in
a backing bean class). JSF provides sufficient infrastructure to make
this fairly straightforward.
The standard JSF components don't do anything particular in terms of
client side scripting (with minor exceptions). That doesn't mean a
component can't do so -- it just means that (for JSF 1.0/1.1 at least)
JSF doesn't provide you any particular help.
It's pretty straightforward to think about some sort of a "panel"
component that does layout management, with "label" and "field"
components you can drop on it -- and some more complicated things ike
a "tree control" or a "sortable table" that you can use to display
volumes of data in interesting ways. It's also pretty easy to imagine
a server side implementation of these sorts of components (the
standard ones that come with JSF get you most of the way) that depend
on a complete page refresh. But that's by no means the only thing
that is possible.
Switch your JSF renderers to something smarter and those same
components can be used to render a description (in XML or JS objects
or whatever you like) of what the panel should look like, along with
its constituent parts, and pass that off to the client for actual
processing. While you're at it, provide (inside your component
definitions) a way to do back channel communication to the server so
that the "submit button" doesn't really do that -- instead it
marshalls all or part of your data and waits for incremental updates
coming back. And, if you want to get fancier, make the scrolling
controls on your tree control ask for the next or previous page's
worth of data via the back channel, instead of rerendering the entire
page.
For JavaOne 2003, we built a primitive version of this for a demo that
used SVG as a client side rendering technology -- the renderers just
created an XML abstraction representing the page and sent that off to
the client, where it was converted into actual SVG markup that was
then executed. The test application was the standard "car demo" app
that comes with the JSF RI -- we kept the components and the back end
logic, but benefitted from cool stuff that SVG enabled on the client
side. We didn't go as far as the back channel communication step, but
there's prior art for how to do that, which JSF components can take
advantage of.
The key is that I can use a tool to build that application, or even
code the tags into a JSP page by hand, and get *either* kind of
support. JSF (in the current generation) doesn't provide you any API
support for the client side components or the communications channel
-- but it provides you a very easy way to capture the design intent of
the page author, hiding the complexitly of the communications channel
inside the renderers where it belongs.
It's feasible to use technologies that require your page authors to be
intimately familiar with serializing Javascript objects, or parsing
XML, and so on -- but that limits the potential audience to those that
have the technical skills to understand them. On the other hand, I've
seen a demo of a JSF tree control whose backing tree had several
thousands of elements in it, which did exactly the partial refresh
trick (dynamically grabbing data as needed when you expand a node) --
but you'd never know it from looking at the couple of simple tags in
the JSP page.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]]
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 30 Oct 2004 00:50:17 -0400, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> I need to look at those links in a little more detail... At a glance I'm
> not sure they fulfill the same goal (although they look to be without a
> doubt very cool!)... I need to evaluate them more though to be sure.
>
> I agree 100% with your comment about remote scripting... I think there
> was a big movement a few years ago in the direction of having the server
> do everything, and I never quite agreed with it. It amazes me all the
> hoops people jump through to try and get web applications too look, feel
> and work like fat clients, and in the end so many fail. That's also the
> reason we get something like XUL which, while neat, is kind of redundant
> in my mind because it's all possible with client-side scripting, CSS and
> DOM manipulation, if you know what your doing.
>
> For example, one app I wrote a couple of years back used something
> called IBM Web Templates (IWT) to talk to Cobol apps running in CICS.
> There was no app server, just a simple web server running on a Unix
> partition on a mainframe that had the IWT extensions installed.
> Basically what I wound up doing was creating an app that was 100% on the
> client... When you accessed the initial URL, you downloaded into a
> frameset a whole bunch of different pages (about 30 as I recall), each
> wrapped in a div. The correct screen was made visible when appropriate,
> and it was populated with data that was returned to a hidden frame... So
> in other words, pages as displayed to the user were never actually
> rendered by the server, it was all done client-side, so the entire app
> can be thought of as a client-side app doing a bunch of RPC calls in
> essence. Basically, the flow was submit a form to the web server, it
> uses these IWT macros to call the Cobol apps, you get back the data
> which is inserted into a resultant HTML page that is nothing but
> Javascript variables and a "bootstrap" Javascript function that calls a
> function in a hidden API frame that knows how to transfer the data from
> the returned Javascript variables to the appropriate screen fields, and
> that's the way the whole system worked. No session (any persistent info
> is stored in a hidden frame), no app server to do any processing,
> nothing like that. Yet the entire app was just plain-old HTML and
> Javascript and a lot of dHTML manipulations. And I'll tell you what...
> the app has literally fooled some people into thinking they were using a
> VB app, and the performance is mind-blowing because it's all dependent
> on the client, and as long as they are moderately powerful, it's all good.
>
> That's the extreme, I don't advocate something like that these days, but
> nor do I like apps that are completely server-bound. Something in the
> middle is what I tend towards now... just enough scripting to make the
> app work like a fat-client, but not so much as to make the code
> exceedingly difficult.
The app you describe does sound a little more extreme than one might
want, but I think it's a great illustration of what can be done with
JavaScript on the client. The primary app I work on in my day job also
uses huge amounts of client side JavaScript to give the user a
near-desktop experience. It enables us to provide functionality that
just isn't possible with a server side rendering model. Our early
attempts at this resulted in pretty horrible performance because of
the amount of JavaScript we were downloading, but now that we've tuned
things up (caching, compressing, minimizing downloads, etc.),
performance is pretty awesome, and orders of magnitude better than
where we started.
> Ah well, guess I got a bit off-topic there. Sorry :)
Actually, I don't think this is off-topic at all, given the Shale
discussions. I think more people on this list need to be enlightened
as to the possibilities of not tying the presentation layer to the
server. In particular, I think we need to give careful consideration
to the JSF issue, since that framework seems particularly unfriendly
to the partial page rendering model.
To my knowledge, anyway, JSF is page oriented, relies on a page's
component tree for rendering / processing, and does not provide for a
client-side component to communicate back to its server-side partner
without serialising and deserialising the page tree along with it.
That pretty much breaks the partial page rendering scheme right there,
unless you have the client and server parts of your components
communicate with each other "out of band" as it were, which kinda
defeats the purpose of having a component based framework.
--
Martin Cooper
>
> --
>
>
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> Don Brown wrote:
> > I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/ -
> > and have used it successfully in several projects, an ASP application
> > and a Struts-based application. I've heard of others, but that one
> > has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
> >
> > This also seems to be a good list of non XML-RPC remote scripting for
> > Javascript: http://www.ashleyit.com/rs/main.htm
> >
> > I've never understood why XML-RPC and remote scripting in general
> > haven't been more prevelent in web applications. The main limitation
> > is a semi-recent browser, but that shouldn't be an issue in most web
> > applications, especially within intranets. The excellent performance
> > and developmental simplicity make web applications viable for more
> > complex tasks.
> >
> > Don
> >
> >
> > On Sat, 30 Oct 2004 00:18:08 -0400, Frank W. Zammetti
> > <fz...@omnytex.com> wrote:
> >
> >>It sounds like what your saying is that such a beast already exists...
> >>I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/,
> >>specifically the link to Client Classes... Is this what your referring
> >>to? If so, I think this is dealing with writing a Java-based client,
> >>not Javascript objects. Assuming that's not it though, can you point me
> >>in the right direction? I'm most definitely interested!
> >>
> >>--
> >>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
> >>><fz...@omnytex.com> 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
> >>>>><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: 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: 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: 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
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java
object conversions]]]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I need to look at those links in a little more detail... At a glance I'm
not sure they fulfill the same goal (although they look to be without a
doubt very cool!)... I need to evaluate them more though to be sure.
I agree 100% with your comment about remote scripting... I think there
was a big movement a few years ago in the direction of having the server
do everything, and I never quite agreed with it. It amazes me all the
hoops people jump through to try and get web applications too look, feel
and work like fat clients, and in the end so many fail. That's also the
reason we get something like XUL which, while neat, is kind of redundant
in my mind because it's all possible with client-side scripting, CSS and
DOM manipulation, if you know what your doing.
For example, one app I wrote a couple of years back used something
called IBM Web Templates (IWT) to talk to Cobol apps running in CICS.
There was no app server, just a simple web server running on a Unix
partition on a mainframe that had the IWT extensions installed.
Basically what I wound up doing was creating an app that was 100% on the
client... When you accessed the initial URL, you downloaded into a
frameset a whole bunch of different pages (about 30 as I recall), each
wrapped in a div. The correct screen was made visible when appropriate,
and it was populated with data that was returned to a hidden frame... So
in other words, pages as displayed to the user were never actually
rendered by the server, it was all done client-side, so the entire app
can be thought of as a client-side app doing a bunch of RPC calls in
essence. Basically, the flow was submit a form to the web server, it
uses these IWT macros to call the Cobol apps, you get back the data
which is inserted into a resultant HTML page that is nothing but
Javascript variables and a "bootstrap" Javascript function that calls a
function in a hidden API frame that knows how to transfer the data from
the returned Javascript variables to the appropriate screen fields, and
that's the way the whole system worked. No session (any persistent info
is stored in a hidden frame), no app server to do any processing,
nothing like that. Yet the entire app was just plain-old HTML and
Javascript and a lot of dHTML manipulations. And I'll tell you what...
the app has literally fooled some people into thinking they were using a
VB app, and the performance is mind-blowing because it's all dependent
on the client, and as long as they are moderately powerful, it's all good.
That's the extreme, I don't advocate something like that these days, but
nor do I like apps that are completely server-bound. Something in the
middle is what I tend towards now... just enough scripting to make the
app work like a fat-client, but not so much as to make the code
exceedingly difficult.
Ah well, guess I got a bit off-topic there. Sorry :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Don Brown wrote:
> I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/ -
> and have used it successfully in several projects, an ASP application
> and a Struts-based application. I've heard of others, but that one
> has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
>
> This also seems to be a good list of non XML-RPC remote scripting for
> Javascript: http://www.ashleyit.com/rs/main.htm
>
> I've never understood why XML-RPC and remote scripting in general
> haven't been more prevelent in web applications. The main limitation
> is a semi-recent browser, but that shouldn't be an issue in most web
> applications, especially within intranets. The excellent performance
> and developmental simplicity make web applications viable for more
> complex tasks.
>
> Don
>
>
> On Sat, 30 Oct 2004 00:18:08 -0400, Frank W. Zammetti
> <fz...@omnytex.com> wrote:
>
>>It sounds like what your saying is that such a beast already exists...
>>I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/,
>>specifically the link to Client Classes... Is this what your referring
>>to? If so, I think this is dealing with writing a Java-based client,
>>not Javascript objects. Assuming that's not it though, can you point me
>>in the right direction? I'm most definitely interested!
>>
>>--
>>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
>>><fz...@omnytex.com> 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
>>>>><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: 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: 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]]
Posted by Don Brown <do...@gmail.com>.
I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/ -
and have used it successfully in several projects, an ASP application
and a Struts-based application. I've heard of others, but that one
has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
This also seems to be a good list of non XML-RPC remote scripting for
Javascript: http://www.ashleyit.com/rs/main.htm
I've never understood why XML-RPC and remote scripting in general
haven't been more prevelent in web applications. The main limitation
is a semi-recent browser, but that shouldn't be an issue in most web
applications, especially within intranets. The excellent performance
and developmental simplicity make web applications viable for more
complex tasks.
Don
On Sat, 30 Oct 2004 00:18:08 -0400, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> It sounds like what your saying is that such a beast already exists...
> I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/,
> specifically the link to Client Classes... Is this what your referring
> to? If so, I think this is dealing with writing a Java-based client,
> not Javascript objects. Assuming that's not it though, can you point me
> in the right direction? I'm most definitely interested!
>
> --
> 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
> > <fz...@omnytex.com> 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
> >> > <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: 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: 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
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java
object conversions]]]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
It sounds like what your saying is that such a beast already exists...
I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/,
specifically the link to Client Classes... Is this what your referring
to? If so, I think this is dealing with writing a Java-based client,
not Javascript objects. Assuming that's not it though, can you point me
in the right direction? I'm most definitely interested!
--
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
> <fz...@omnytex.com> 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
>> > <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: 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]]
Posted by Don Brown <do...@gmail.com>.
On Fri, 29 Oct 2004 23:52:49 -0400, Frank W. Zammetti
<fz...@omnytex.com> 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
> > <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: 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