I can see where you're going with the mixing of business logic and views. I will admit that in parts i have done this. A quick javascript check gives a much quicker response that submit/redisplay form. Especially when you get some of the massive pages in our system. One solution i had was to do both. The javascript deals with validation, for the user, but the business logic also validates data using actionforms, and only proceeds if it passes.
Cheers for the span tip. It will reduce some of my needs for double requests. However sometimes the iframe saves requesting more than necessary in the response - eg when searching data, only replace the inside of the iframe. Daniel. > -----Original Message----- > From: Frank Zammetti [mailto:[EMAIL PROTECTED] > Sent: 04 June 2004 17:08 > To: [EMAIL PROTECTED] > Subject: RE: [OT] thick client functionality in the browser > > > > >I agree with this. Our app is IE only, and it's amazing what you can do. > >IFRAME's make great scrollable tables. The use of > >document.getElementById("xxx").style.display="none" (or "") for > >hiding/unhiding stuff is very extensive. > > You know what I discovered about a month ago? Instead of using > iFrames, you > can get the same functionality with a <span> with > style="overflow:scroll;". > In every way I can determine, it looks and works the same, but > now instead > of either having the server serve a second page to populate the iFrame or > having script generate the HTML for it when the parent loads > (which I did a > lot of previously), you can how use regular JSP code (taglibs > hopefully!) to > generate the HTML inside the <span>. It speeds things up so much! > > >I disagree with the comment about layers tho. Our jsps are still only > >displaying stuff. They arnt doing anything that the business > layer should > >atall. > > > >Javascript/dhtml is amazing if you persist with what you want. I came > >accross a webmail system the other day that i couldnt believe wasnt using > >anything else for gui! > > I agree, you certainly CAN maintain good architecture. That's where my > story about my past three apps came in, how the most recent was is > infinitely better in terms of separation of layers. > > The point I was trying to make, probably not very well, is that > it's EASIER > to screw up this way. You can easily become tempted to put pieces of > business logic in the view because you realize "gee, if I do x, y > and z via > scripting I don't have to have the server do it!". Things like > validations > for example... just checking if a field is filled in is of course > fine to do > with script, but if you start doing "if field X is greater than > the maximum > dollar amount allowed for this account" in script just because > you happen to > have that data on the client-side at the time, that's where you run into > problems. It's tempting because you CAN do it in script and the > result is a > snappier interface that is less error prone (because of reduced network > activity and server load), but it's not good architecturally. > It's not that > dHTML and scripting MAKES you make bad choices, just that it > makes it easier > and more attractive in many cases. That's what I was trying to say, > hopefuly I did a better job this time :) > > >Daniel. > > > > > -----Original Message----- > > > From: Frank Zammetti [mailto:[EMAIL PROTECTED] > > > Sent: 04 June 2004 16:41 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [OT] thick client functionality in the browser > > > > > > > > > I've personally made something of a career out of doing what your > >talking > > > about. The applications I've built at work are known to have very > > > Windows-like look, feel and functionality, much more so than > most other > > > web-based applications. > > > > > > To pull it off, two things are true... first, it is IE only. This is > > > because of the secone: they are very heavily JavaScript, Dynamic HTML > >and > > > CSS-based GUIs. > > > > > > It *IS* possibly to do this type of thing in a cross-browser > > > fashion, but I > > > think it's fair to say it is considerably harder, and certainly more > > > time-consuming. Standardizing on IE for us was easy because it's > >already > > > the corporate standard, and is for 99% of our clients (the other 1% we > > > simply tell they either use IE for at least our apps our they > > > don't use the > > > apps... not too nice in my mind, but it's been accepted thus far). > > > > > > Whether you try to do it cross-browser or not, most of your > time will be > > > spent doing scripting. You can do some truly amazing things that > > > will make > > > you forget your looking at a web-based app, for the most part. > > > You can also > > > in many cases get much better performance because the more > you do on the > > > client (assuming it's not processor-intensive since your > talking about > >an > > > interpreted scripting language), the better PERCIEVED performance the > >app > > > can have in many cases. A good example is one application > where I sort > >a > > > returned list of search results on the browser as a result of a > > > click of a > > > column header in an iFrame, which makes it work just like a grid > > > in Windows. > > > People love that, and so do the server admins since I'm not > having the > > > server sort search results. > > > > > > There are absolutely trade-offs you have to be aware of along the > > > way, but > > > this is the way I'm pulling it off, and the way I think most > people are, > > > without resorting to plug-ins, Flash, Applets, ActiveX and all > > > that sort of > > > stuff. Pure HTML and JavaScript (well, as pure as you can > get when it's > > > IE-only!), and you get what you want without most of the headaches. > > > > > > The other big thing to consider is that you VERY quickly > break "proper" > > > application architecture, i.e., separation of layers. It's almost > > > unavoidable when your doing something like this unless you are > > > exceptionally > > > careful. I've done three huge applications along these lines > > > over the past > > > four years, the first two were pretty poor in terms of > > > separation, the third > > > is actually very good, but I learned a lot of lessons from the first > >two, > > > and even still there are things done that probably shouldn't be. If > >this > > > isn't your biggest concern (as it's not here since fulfilling client > > > requests always trumps proper application development, bad as > > > that may be in > > > theory!), then it's fine. If your an absolute architecture > > > purist (i.e., if > > > your a Ph.D, which we have way too many of these days!), then you'll > > > probably fight such an approach tooth and nail, and continue to > > > either (a) > > > have trouble with how your applications work or (b) develop less > >powerful > > > interfaces because your more concerned with the structure of an > > > application > > > than what it looks like and feels like and works like for an end user. > > > > > > Now that I've opened a theological nightmare here... ;) > > > > > > Frank > > > > > > >From: "Wennberg, Mathias" <[EMAIL PROTECTED]> > > > >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > > >To: <[EMAIL PROTECTED]> > > > >Subject: [OT] thick client functionality in the browser > > > >Date: Fri, 4 Jun 2004 10:25:41 -0500 > > > > > > > >We're currently running a swing java webstart app but issues > > > with clients > > > >jvm > > > >versions and permissions to install/update programs on their > > > workstations > > > >are > > > >making us look into alternatives. > > > >What are people out there using to get thick client functionality in > >the > > > >browser? Ultimately it would work without any plug-ins and on > > > all browsers, > > > >but it's not necessary as long as it works on IE and doesn't use > >activeX. > > > > > > > >I'm also looking for comments and feedback on thinlets and canoo. > > > > > > > >Thanks. > > > > > > > >--------------------------------------------------------------------- > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > _________________________________________________________________ > > > MSN Toolbar provides one-click access to Hotmail from any Web page – > >FREE > > > download! > http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/ > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > _________________________________________________________________ > MSN Toolbar provides one-click access to Hotmail from any Web page – FREE > download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/ > > > --------------------------------------------------------------------- > 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]
