Marc Eckart wrote:
The most applications are hosted in the intra net. We have another subnet
with some Websphere servers secured by firewalls but they can all be
accessed within out domain. So I think I'm back with frames respectively
iframes :-)
Sounds like it :) Yeah, I'd definitely think iFrames vs. regular frames
here, sounds much more appropriate to what you're doing.
One hint that might help... the document.domain property of each page
can be manipulated to cover subdomains. For instance, if your "main"
app is on mycompany.com, and you have to have app2.mycompany.com hosted
in a frame, and you need to do cross-frame scripting between them, you
can set document.domain to mycompany.com on both, which then allows the
cross-frame scripting to occur. The limitation is it has to be the same
base domain, but that allows you to bring subdomains into the picture.
It's only when you have totally different domains (mycompany.com and
othercompany.com say) that cross-frame scripting is impossible (or,
dicey and requiring hackery at best).
With that one hint in mind, you're probably good to go :)
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!
Thank you all for your answers :-)
Best Regards,
Marc
2008/2/13, Frank W. Zammetti <[EMAIL PROTECTED]>:
Marc Eckart wrote:
Hmm, in our case the single applications should not know it they are
running
in a portal or somewhere else. They should just see their context,
nothing
else.
In my experience, which I admit was a while back and fairly limited, a
portlet is specifically written as a portlet, i.e., it knows it's
running within a portal and acts accordingly. Your requirements seem to
say otherwise, so I'm thinking one strike against a portal approach.
Another question to hold the application in simple divs:
How does the action handling works if I include the applications in
simple
divs? If they redirect after an action to a jsp will they stay in the
div or
fill the whole page?
Those types of things would affect the larger page, without modifying
the application hosted in the <div>. I'm thinking that's a strike
against a simple <div>-based approach.
Kind of coming back to frames I think :) The question then is whether
frames is viable or not... if the apps are all hosted under the same
domain, your life is a lot easier. If not, trouble abounds!
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!
2008/2/13, Randy Burgess <[EMAIL PROTECTED]>:
I would imagine that it is portal specific. It is up to the developer
with
AquaLogic.
Regards,
Randy Burgess
Sr. Web Applications Developer
Nuvox Communications
From: "Frank W. Zammetti" <[EMAIL PROTECTED]>
Reply-To: Struts Users Mailing List <user@struts.apache.org>
Date: Wed, 13 Feb 2008 09:45:34 -0500
To: Struts Users Mailing List <user@struts.apache.org>
Subject: Re: OT: Alternative to html frames
So that seems to say that it's left to the portlet developers to
ensure
there are no naming conflicts, am I understanding that right?
Frank
Randy Burgess wrote:
As to the multiple identical portlets on the same web page question,
I
think
most portals have a portlet id for each portlet or some other unique
identifier. It is a best practice to append the portlet identifier
onto
function names, form names in the case of Struts 2 with client side
validation, etc. Here we are developing for the BEA AquaLogic portal
and we
use the portlet id, which is numeric and unique for each portlet.
Regards,
Randy Burgess
Sr. Web Applications Developer
Nuvox Communications
From: "Frank W. Zammetti" <[EMAIL PROTECTED]>
Reply-To: Struts Users Mailing List <user@struts.apache.org>
Date: Tue, 12 Feb 2008 10:36:08 -0500
To: Struts Users Mailing List <user@struts.apache.org>
Subject: Re: OT: Alternative to html frames
Antonio Petrelli wrote:
Frank, you might love this article :-)
http://thedailywtf.com/Articles/I-am-right-and-the-entire-Industry-is-wrong
.a
spx
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]
This email and any attachments ("Message") may contain legally
privileged
and/or confidential information. If you are not the addressee, or if
this
Message has been addressed to you in error, you are not authorized to
read,
copy, or distribute it, and we ask that you please delete it
(including
all
copies) and notify the sender by return email. Delivery of this
Message to
any person other than the intended recipient(s) shall not be deemed a
waiver
of confidentiality and/or a privilege.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
This email and any attachments ("Message") may contain legally
privileged
and/or confidential information. If you are not the addressee, or if
this
Message has been addressed to you in error, you are not authorized to
read,
copy, or distribute it, and we ask that you please delete it (including
all
copies) and notify the sender by return email. Delivery of this
Message to
any person other than the intended recipient(s) shall not be deemed a
waiver
of confidentiality and/or a privilege.
---------------------------------------------------------------------
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.4/1275 - Release Date:
2/12/2008 3:20 PM
---------------------------------------------------------------------
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.4/1275 - Release Date: 2/12/2008 3:20 PM
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
