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]
