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

["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