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
--
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!
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]
------------------------------------------------------------------------
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
