I have no objections :) khalid
Quoting Frank Zammetti <[EMAIL PROTECTED]>: > >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. > > You know, I'm sitting here wondering why I never just refreshed the > iFrames?!? Kind of DUH moment for me! > > On something else relevant... My applications are also frame-based, which I > know many people hate, but that's something else that will allow you create > richer interfaces in my opinion. First, you can have portions of the screen > that never change, that's what I've done a lot of. All three applications > that I referred to have similar appearance, that is, they start by opening a > new window with no chrome (i.e., just an empty frame, no browser buttons or > menus or anything), and in this I load a frameset that usually consists of a > menubar up top, a bar on the left and a status bar on the bottom, plus a > main frame in the middle of it all. Only the middle frame ever changes, all > the others are never loaded after the first time. I change their content > via script functions in an API. > > The API is the other important thing... I create a hidden frame (just set > it's size to 0 in the frameset) and in this frame I load a large collection > of script functions that are used throughout the application. The benefit > here is that all that stuff doesn't have to be retrieved with each request. > So, these functions form an API for the application, maybe I have a > setStatusMessgage() function, and a loadSidebar() function, things like > that. > > What I do is when I call on the server to generate a page for the main > frame, I display a "Please Wait" layer that is included in all the main > pages the server renders. I also hide the content in the other frames. So, > I get a nice waiting screen while the server is loading (usually with some > kind of animation, a clock spinning for instance). When the page is > returned, it by default has the same Please Wait layer showing and it's main > content hidden, the appearance is that the Please Wait screen is showing > until the page is completely loaded. Very nice. Then I hide the Please > wait layer and show the main content, but not before the appropriate > functions in the API are called to set up the other frames (i.e., status > message, links on the sidebar, etc). > > The other benefit to this hidden API frame is that you can store persistent > data in there in JavaScript variables and use them on many different pages. > This is how I do the client-side sorting stuff... I load an array in that > frame, then render the mani frame's contents off that array. When the user > wants to sort by a different column, just call the sort() function and > re-render the contents (done in one call actually). > > These are just some of the tricks I've developed over the years. If anyone > wants to discuss this further, I'm all for it, but I'm not sure how > appropriate it is to the Struts list. If people are interested though, and > no one objects, it might make a nice thread, something like "Rich GUI > tricks" or something. > > Frank > > >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] > > > > _________________________________________________________________ > 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] > > -- Khalid K. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
