"Lerenc, Vedran" wrote:
> > 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.
>
That is good. We have been discussing the issues previously, and I think a
component around these lines will be needed in Jetspeed.
>
> 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?
>
With regards to the chaining of portlet requests, it does not look natural to
me. It belongs more to a product like Cocoon. Even if there are no good
mechanisms today for rendering XML content in the Servlet API, I'm quite sure
that they will appear, as the compilation of SAX events in Cocoon and other
ideas we spoke about at the ApacheCON are quite natural to be extended as a
different mechanism from the ByteStream based one currently in servlets. I even
used the word SAXlets, meaning precisely this, in a previous post.
I understand by a SAXlet an object that will generate/transform content in a
stream of SAX events, mostly like the Cocoon2 architecture producers,
transformers and renderers do. It would be something similar to servlets, but
much more natural in a XML environment. The servlet API should be extended in
the future to deal with the mix of these objects and "standard" servlets, as
chaining SAX events is simpler than having to regenerate XML and re-parse at the
next inclusion level.
I hope that the Jetspeed API will be able to handle the three kinds of portlets:
- ByteStream based (Servlets or legacy HTTP requests)
- Object Tree based (ECS, DOM, other implementations, mostly legacy due to the
lack of escalability WRT tree size, but maybe useful in some contexts)
- SAX event Stream based (Somethind that will generate, receive or filter events
from other components in a chain, that will eventually end in the generation of
a ByteStream to the client)
The results produced by the last two classes of portlets will be very oriented
to the kind of transformations that we will need to render a page. Currently we
are doing it with the second kind only.
The first class will be more difficult to handle, specially in terms of resource
needs. There is where specialized objects, like the AdvancedFileServer, could
play a role. But I don't think we will need to chain portlets. I would say that
this functionality belongs to a lower layer, like Cocoon pipelines or Servlet
programming.
>
> 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]
--
--------------------------------------------------------------
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]
