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]
