In AquaLogic there is a feature called In Place Refresh, which stops a portlet from taking over the page due to a redirect or whatever. You can use divs if you want but I have portlets without a single div. With AquaLogic you can use JSR 168 portlets or not, if you don't want to. Since I have this option I have been creating plain old S2 actions that also run as portlets. We have also created interceptors to facilitate providing portal services to actions that require them.
Regards, Randy Burgess Sr. Web Applications Developer Nuvox Communications > From: Marc Eckart <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <user@struts.apache.org> > Date: Wed, 13 Feb 2008 16:44:17 +0100 > To: Struts Users Mailing List <user@struts.apache.org> > Subject: Re: OT: Alternative to html frames > > 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] >> >> 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]
