> Of course things are much more complicated if we are talking about > portlets that include legacy pages and the targets are not portlets > that follow a certain programming model but arbitrary web > applications. > I guess the mails posted by Marcus Schwarz and Vedran Lerenc > give a good > impression of the problems that occur in these scenarios. > > I think we need to differentiate between two different scenarios: > > - Implementation of portlets exploiting the portal's Portlet API and > Framework, adhering to applicable design guidelines. > > - Implementation of portlets that encapsulate legacy web applications, > where these legacy apps cannot be changed. > > The Portlet API and framework should allow for easy and efficient > implementation of portlets for the first scenario. > > For handling the second scenario, complicated mechanisms for > rewriting, > handling of cookies and probably other issues may be built into the > portal implementation, but they should not impact the portlet API. Hmm, if this functionality would be build into the portal, then it should be possible to switch it on and off, because it's quite time consuming and not neccessary to perform for well known portlets (first scenario). Therefore we have chosen the way of the AdvancedFileServer model. If we want to incorporate a not well known source (second scenario), we set the portlet's parent to our AdvancedFileServer and define it's behaviour using portlet parameters (rewrite URLs or not, etc.). Following this approach we are quite separated from the core, but still, we could make use of the generated portal page's header or table row/cell the portlet is copied into. I would think that the portlet API is a way to access that information. If we take a closer look, it seems quite legitimate to have access to the generated portal page - after all we also have access to the HTTPServlet response which is part of the actual "portlet API". Both, content and response belong together, because the content is generated using the response's writer. But that's just a minor issue, born out of out problems getting the whole picture, when being limited by the current architeure and view of a single portlet, not knowing what's around on the page. You could also think about a more advanced portlet communication infrastruture then we have implemented so far using HTML form input parameters, escaped and sent between portlets by reloading the portal page. That surely is an interesting topic for the portlet API. We at our project had such requirements, so we added this feature in a very rough way to our AdvancedFileServer. Another issue is that only one portlet object is run to render a portlet's view, e.g. you may only specify the AdvancedFileServer to render an external source, but what if this source serves content based on a Cocoon transformation? You would have to implement something combining the AdvancedFileServerPortlet and CocoonPortlet. What about portlet chaining/pipelining, i.e. setting up a chain like having a source rendered by the CocoonPortlet and then rendering the result by the another portlet, like the AdvancedFileServerPortlet? Thanks for taking these thoughts into consideration, Vedran -- -------------------------------------------------------------- Please read the FAQ! <http://java.apache.org/faq/> To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: <http://java.apache.org/main/mail.html> Problems?: [EMAIL PROTECTED]
