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.)
Regards,
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 <[EMAIL PROTECTED]>:
Antonio Petrelli wrote:
Frank, you might love this article :-)
http://thedailywtf.com/Articles/I-am-right-and-the-entire-Industry-is-wrong.aspx
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 - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
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]
