On Sat, 30 Oct 2004 14:33:12 -0400, Frank W. Zammetti <[EMAIL PROTECTED]> 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 > >>><[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] > > > > > > > > > > > > --------------------------------------------------------------------- > 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]
