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]
