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.
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? 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] > >
