struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: OT: Alternative to html frames
Date Tue, 12 Feb 2008 18:08:37 GMT
I think it all comes down to whether the "different application/jsp"'s 
are in the same domain.  If they are, then iFrames might do the trick 
nicely.  Note that even if they are different subdomains, you can still 
do cross-frame scripting, it just requires some playing around with the 
document.domain attribute (this isn't something I've personally had to 
do, but I've read about it).  If it's entirely different domains, then 
you're pretty close to dead in the water with frames (Brantley hinted at 
some ways around this in his reply, but it's probably fair to say that 
all those ways fall in the category of high hackery, so I for one would 
tend to avoid them).

Why your bottom frame gets "kicked out" when you get your customer 
details, I'm not sure... I think you must be submitting a form in the 
bottom frame that has no target, and therefore it replaces what's in 
that frame.  That makes sense, and it's what it should do.  What you'd 
need to do instead is target a different frame, so the results of the 
submit appears there.  It may be your top frame, or it may be a third 
frame that you need to add and organize so it's in the right place 
relative to your existing frames.

But, I'll also say this: from what you've said, it doesn't really sound 
like you have truly independent applications to host.  If that's the 
case, then iFrames probably *aren't* the write choice, something more 
AJAXy with <div>'s almost certainly is.  If everything is within the 
same domain (which doesn't mean the same server necessarily remember), 
then iFrames vs. <div>s is pretty close to a wash for all intents and 
purposes (with the caveats Brantley enumerated still being valid).  I'd 
probably go with <div>s in that case just for the sake of simplicity and 
being more "politically correct", but in practice the differences 
wouldn't be *that* great.

By the way, anyone that says X, Y or Z is EVIL and should never be used 
is, in my opinion, very likely not worth listening to.  As much as I 
dislike JSF, and am on record numerous times as saying as much, I've 
also always said it may well be the right choice in some situations. 
I've never, as far as I remember, said it was evil and should never be 
used, and people would be right to simply ignore me if I did.  Same goes 
for iFrames, or anything else.  There's certainly some things to 
consider before choosing iFrames, as Brantley pointed out, but someone 
that simply dismisses them out of hand as your colleague seem to be 
doing probably isn't the first person who's opinion you should put much 
stock in :)

I mean, we've all heard the admonishment about not using a screw driver 
as a hammer because it's not the right tool for the job, and we'd all 
agree with that I'm sure.  But, sometimes a screwdriver is all you have, 
so a screwdriver it is!  And what's more, you might be working in a 
confined space where a hammer wouldn't fit, but a screwdriver does :)


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!

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:
> ------------------------------------------------------------------------
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.516 / Virus Database: 269.20.2/1272 - Release Date: 2/11/2008 5:28 PM

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

View raw message