Hi Frank, thank you and all others for your answers ;-)
We have a similar aproach like you described. We have an application which acts as a portal. This application has two frames - one top frame for the navigation and another frame for hosting the embbeded (independet) application. One of this embbeded application is a customer search where you can select a customer, who can be used in another application. We have a customercontext, which exchanges the data of the customer between the applications. So the selected customer is just shown in the customer search and it is necessary to reimplement the displaying of the selected customer in every application where it should appear. So I want to put the displaying of the selected customer in the portal top frame to have it visible for all applications. The Problem is, when I want to display customer details, I have to call a different application/jsp which should display the details. But this whatever kind of display kicks the current application out of the bottom frame. That's when my thinking went to iframe :-) So I now have just one website, no frameset and I can put a ajax filled div tag over the iframe to display the customer details (I haven't tested this yet, so I don't know if it's really working :-) I asked some colleagues, what they think about it and they said iframes are EVIL :-) So thats why I asked to have another oppinions. I'm not sure if portlet container can help me with this issue. Best regards, Marc 2008/2/12, Frank W. Zammetti <[EMAIL PROTECTED]>: > > Antonio Petrelli wrote: > > Frank, you might love this article :-) > > > http://thedailywtf.com/Articles/I-am-right-and-the-entire-Industry-is-wrong.aspx > > > 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] > >
