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