On Wed, April 8, 2009 10:32 am, Russell Jones wrote:
Jon and Frank, you might be interested to look at the proposed additions
to iframe in HTML5. I'd be interested in what you make of them and if
you have any other ideas for how the tag could be further improved.

Interesting. The seemless attribute strikes me as interesting. I could
see where that might solve some of the issues we see today like when you
time out in an iFrame but not the parent, etc.

I'll tell you a few relatively simple things that, to me, would pretty
well make iFrames perfect in every way...

First, have the browser automatically append the ID of the iFrame to all
IDs in the loaded document, and load all scripts into a namespace based on
that ID.

Second, any JavaScript in the parent called from an iFrame would execute
within the context of THE IFRAME by default. Therefore, calling
parent.dojo.byId() would operate on the iFrame's DOM, not the parent's
DOM. Of course, provide a mechanism to reverse that, but make it work
that way by default. Sure, it's not backwards-compatible, but I think
it's the better answer.

The point is, with some (conceptually) simple changes, you could
guarantee uniqueness of all names in both script land and DOM land, and
make sharing of JavaScript much more straightforward.

Now, I haven't thought through all the security considerations with these
suggestions... I have no doubt there's big, huge holes here :) Just
thinking out loud.
I guess the main thing with iframes is to realise the constraints they
impose as well as the benefits, and to at least consider other ways of
accomplishing the task at hand. For instance, IIRC, a subclass of the
ContentPane can be set to load a page from a URL, either when parsed or
dynamically, converting the content of the body tag to an HTML fragment.
I forget how the content of the head tag is handled.
Agreed. iFrames certainly aren't the answer to every problem. In our
case though, without looking at various portlet specs at least, there
wasn't too many choices. For us, the design decision has turned out
REALLY well.
Russell Jones

Frank W. Zammetti
Author of "Practical Ext JS Projects with Gears" (coming soon)
and "Practical Dojo Projects"
and "Practical DWR 2 Projects"
and "Practical JavaScript, DOM Scripting and Ajax Projects"
and "Practical Ajax Projects with Java Technology"
(For info: apress.com/book/search?searchterm=zammetti&act=search)
All you could possibly want is here: zammetti.com
Frank W. Zammetti wrote:
On Wed, April 8, 2009 10:02 am, Jon Sykes wrote:

We found it's just easier to give each iframe it's own and then manage
the cross doc communications and use lots of topics for pub/sub cross
Ditto. I lead development of a very large and complex application that
uses Dojo (among a number of other libraries) and it's premised on their
being iFrames because we're essentially hosting other applications
developed by other teams, so we're something of a portal, and you simply
couldn't pull it off without iFrames (think just of trying to manage DOM
IDs to avoid naming conflicts across multiple teams!)... although, the
the app is built it looks like a single, unified application, you'd
know from looking at it that there are iFrames or apps running on other
servers, to the user you're simply using different screens in a single

We have our own API that sits in the parent doc that the children can
in a shared fashion, we built it that way from the ground up, but for
(and other libraries) we load a new copy for each app that needs it (not
all of them do). It's not the most memory-efficient way to do things,
it works, and in fact there's probably no real choice in our case.
FAQ: http://dojotoolkit.org/support/faq
Book: http://dojotoolkit.org/docs/book
Forums: http://dojotoolkit.org/forum
Dojo-interest at mail.dojotoolkit.org

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 9 | next ›
Discussion Overview
groupdojo-interest @
postedApr 8, '09 at 6:28a
activeApr 8, '09 at 1:56p



site design / logo © 2018 Grokbase