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]
