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]
