struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brantley Hobbs <>
Subject Re: OT: Alternative to html frames
Date Tue, 12 Feb 2008 17:15:53 GMT
Ya know, this triggers a question of my own:

I have apps that use *tons* of iframes, and there *are* some drawbacks:

1.  Without some sort of "onload()" built-in to every page, there's no 
way of knowing if the frame has loaded when you update its .src 
attribute.  With an AJAX filled div, you'd know because the 
xmlhttprequest object changes states (of course, there's still rendering 
time, but at least you know your server response came back).
2.  Browsers sometimes render iframes inconsistently (I'm referring to 
the application of style attributes, not to the loading of the iframe).  
Divs are usually a little more predictable.
And the worst:
3.  If you load a frame from some other domain, you really have to jump 
through hoops to get around the cross-domain scripting security features 
built into the browser.

None of these are show-stoppers, but some are annoying enough that I 
started trying to rework my little homebrew application layout with 
divs.  This caused some problems when I realized that simply setting the 
.innerhtml attribute on the div wasn't good enough.  The HTML rendered, 
but things like <script> tags were ignored, making the whole thing 
useless for me.

S2 apparently does something like this (I haven't looked to see how it 
does it yet).  Can someone give me a nutshell description of how to get 
around this problem?

(Sorry to threadjack, but at least I can contribute some useful bits of 
information, instead of a blanket "iframes are EVIL" comment.)

Brantley Hobbs

Marc Eckart wrote:
> Hi Frank,
> thank you and all others for your answers ;-)
> We have a similar aproach like you described. We have an application which
> acts as a portal. This application has two frames - one top frame for the
> navigation and another frame for hosting the embbeded (independet)
> application.
> One of this embbeded application is a customer search where you can select a
> customer, who can be used in another application. We have a customercontext,
> which exchanges the data of the customer between the applications. So the
> selected customer  is just shown in the customer search and it is necessary
> to reimplement the displaying of the selected customer in every application
> where it should appear.
> So I want to put the displaying of the selected customer in the portal top
> frame to have it visible for all applications. The Problem is, when I want
> to display customer details, I have to call a different application/jsp
> which should display the details. But this whatever kind of display kicks
> the current application out of the bottom frame. That's when my thinking
> went to iframe :-) So I now have just one website, no frameset and I can put
> a ajax filled div tag over the iframe to display the customer details (I
> haven't tested this yet, so I don't know if it's really working :-)
> I asked some colleagues, what they think about it and they said iframes are
> EVIL :-) So thats why I asked to have another oppinions.
> I'm not sure if portlet container can help me with this issue.
> Best regards,
> Marc
> 2008/2/12, Frank W. Zammetti <>:
>> Antonio Petrelli wrote:
>>> Frank, you might love this article :-)
>> Hehe :)
>> It's a good example of the typical "taking an idea too far".  The world
>> seems to be divided into the people that say frames are evil and should
>> never be used (and IIRC, they are removed in HTML 5, so apparently those
>> guys feel that way too) or those that say frames are DA BOMB and should
>> always be used.
>> I'm personally in neither camp.  I'm simply someone that has used frames
>> a number of times over the years with great success.  They certainly
>> aren't appropriate in every case, that's why I asked what the problems
>> were that Marc was having.
>> Portals is one way to go, sure.  The last time I touched portals was a
>> couple of years ago frankly, so maybe you could answer a question for me
>> that I'm curious about... if I have a Javascript variable named
>> firstName in two different portlets, how does the container avoid that
>> name clash?
>> For the past nearly two years (can't believe it's been that long!) I've
>> been leading an effort to develop a single, unified back-office
>> application that combines a number of new and existing applications into
>> a cohesive whole.  It's been one of the most successful project to date
>> at my company, and it was only possible because of a frame-based
>> (iFrames in that case) architecture.  We have unique teams developing
>> individual "modules", and there's never a concern about name conflicts
>> with either Javascript or HTML elements.  I'm curious if a portal
>> approach would have worked here too.
>> It's interesting because in a very real sense we pretty much developed
>> our own portal container!  We have a common "Framework" that all the
>> modules make use of, some common bits of functionality that runs across
>> all of them (preferences, dropdown menu, some others).  But they are
>> 100% independent by and large (some of the modules are actually whole
>> other applications hosted on other servers).  Would a portal have
>> allowed for things like that?  If so, do you have any idea how it pulls
>> that off without frames?  Most importantly, avoiding those naming
>> conflicts I mentioned.
>> I don't want to hijack a thread here, but it's already marked OT, and
>> since you've got my curiosity piqued, I'll ask the questions :)
>>> Antonio
>> Thanks,
>> Frank
>> --
>> Frank W. Zammetti
>> Author of "Practical Ajax Projects With Java Technology"
>>   (2006, Apress, ISBN 1-59059-695-1)
>> and "JavaScript, DOM Scripting and Ajax Projects"
>>   (2007, Apress, ISBN 1-59059-816-4)
>> and "Practical DWR 2 Projects"
>>   (2008, Apress, ISBN 1-59059-941-1)
>> Java Web Parts -
>>   Supplying the wheel, so you don't have to reinvent it!
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message