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