A portal implementation is typically quite an undertaking. Frames would be a whole lot easier. :)
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 17:30:38 +0100 > To: Struts Users Mailing List <user@struts.apache.org> > Subject: Re: OT: Alternative to html frames > > The most applications are hosted in the intra net. We have another subnet > with some Websphere servers secured by firewalls but they can all be > accessed within out domain. So I think I'm back with frames respectively > iframes :-) > > Thank you all for your answers :-) > > Best Regards, > Marc > > 2008/2/13, Frank W. Zammetti <[EMAIL PROTECTED]>: >> >> Marc Eckart wrote: >>> 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. >> >> >> In my experience, which I admit was a while back and fairly limited, a >> portlet is specifically written as a portlet, i.e., it knows it's >> running within a portal and acts accordingly. Your requirements seem to >> say otherwise, so I'm thinking one strike against a portal approach. >> >> >>> 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? >> >> >> Those types of things would affect the larger page, without modifying >> the application hosted in the <div>. I'm thinking that's a strike >> against a simple <div>-based approach. >> >> Kind of coming back to frames I think :) The question then is whether >> frames is viable or not... if the apps are all hosted under the same >> domain, your life is a lot easier. If not, trouble abounds! >> >> >> 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! >> >>> 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] >>>> >>>> >>> >>> >> >>> ------------------------------------------------------------------------ >>> >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >> >>> Version: 7.5.516 / Virus Database: 269.20.4/1275 - Release Date: >> 2/12/2008 3:20 PM >> >> >> >> --------------------------------------------------------------------- >> 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]
