[EMAIL PROTECTED] wrote:
>
> Raphael Luta wrote:
>
> > [EMAIL PROTECTED] wrote:
> > >
> > > I'm not sure what exactly you mean - wouldn't different forms in
> different
> > > portlets have different targets to which the parameters would get
> posted ?
> > >
> >
> > I'm not sure it's actually possible but if you have a way for a portal
> > to implement this I'm definitely interested.
>
> I was thinking about something like this: Assume we have several portlets
> in a page, which contain forms. Through a rewriting mechanism,
> the targets of each form could be rewritten to include the portlet ID as
> a parameter. A central request dispatcher could be used to route each
> incoming post request to the portlet with the portlet ID specified in
> the request. However I guess I may be thinking of another scenario than
> you - real portlets designed for use in a portal instead of portlets
> wrapping legacy web apps.
>
I believe we are actually thinking of the same thing: creating a parameter
separation by using an GUID parameter for each instance of a portlet present
in the page. There're may be an additionnal need for namespace separation if
the portal needs some portal-variables set in the same request.
> 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.
>
+1
> 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.
>
I even think such capabilities should be handled by the portlet itself
just like the AdvancedFilePortlet presented. There will never be a proper
way to aggregate different legacy documents in a single page.
>
> I'm not sure how exactly this works ... Could you post a little example
> that shows how an XMLPortlet would generate an HTML page with some XML
> data and how it would output the XML data ?
>
Well, first I think XMLPortlet is not a good name because everything should
be XML in Portlet space, let's call it DataPortlet.
Let's take as an example a MailPortlet which retrieves the content of
a MailBox.
1st case: MailPortlet extends Portlet
The Portal creates a PortletRequest which asks for "luta" mailbox in
XHTML1.0 format, no table (for my PDA). It also creates a PortletResponse
object in which it puts a reference to its HTML serializer as
ContentHandler and then calls the Portlet service method.
The Portlet does the following in its service method:
- get the ContentHandler from the PortletResponse and use it as target
for its generated SAX events.
- get the content of luta mailbox
- set the XML namaespace of the result to XHTML URI.
- format and output the result as XHTML without tables, sending SAX events
as elements are created.
The portal may do several rewritings/filterings of the events before
sending the final output to the client.
2nd case: MailPortlet extends DataPortlet
The Portal creates a PortletRequest which asks for "luta" mailbox in
XHTML1.0, no table format. It creates a PortletResponse object in which it
puts a reference of a PortletRenderer (portal implementation specific) object.
The portal then calls the build() method instead of service().
The Portlet does the following in its build method:
- get the ContentHandler from the PortletResponse and use it as target
for its generated SAX events.
- get the content of luta mailbox
- set the XML namaespace of the result to a well-known mail description
markup.
- format and output the result, sending SAX events as elements are created.
As soon as the PortletRenderer recieves the root element with the namespace
declaration, 2 things may occur:
* the Renderer knows how to render this markup in a system specific, it
forwards the events to a MailRendered element which may be shared by all
portlets in this portal.
* the Renderer does not know how to deal with this markup (maybe it's
proprietary stuff after all), it uses the DataPortlet as ContentHandler
and forwards all the events back to the portlet for rendering (note:
the example API provided does not currently handles how the portlet
forwards its rendered content beck to the portal).
So if the portal knows how to handle the data markup, the processing chain
is:
|
V
MailPortlet.build();
| (data markup)
V
PortletRenderer.startDocument();
|
V
MailRenderer.startDocument();
| (XHTML markup)
V
HTMlSerializer.startDocument();
|
V
output stream sent to client
If it does not know how to handle it:
|
V
MailPortlet.build();
| (data markup)
V
PortletRenderer.startDocument();
|
V
MailPortlet.startDocument();
| (XHTML markup)
V
HTMlSerializer.startDocument();
|
V
output stream sent to client
Note: the service() method of DataPortlet does exactly :
|
V
MailPortlet.build();
| (data markup)
V
MailPortlet.startDocument();
| (XHTML markup)
V
SAX events forwarded to portal
3rd case: MailPortlet extends LegacyPortlet
Now let's imagine the MailPortlet has been written with a tool
designed for using output streams rather than SAX events.
We can use a LegacyPortlet which uses a LegacyPortletResponse :
interface LegacyPortletResponse extends PortletResponse {
public OutputStream getOutputStream();
}
This can be easily supported and mapped to the first case by
piping the generated output into a SAX parser which then forwards
SAX events to the portal. The processing chain is then:
|
V
LegacyMailPortlet.service();
| (XHTML output stream)
V
SAXParser.parseDocument();
| (XHTML events)
V
HTMlSerializer.startDocument();
|
V
output stream sent to client
Comments:
* The nice thing in using SAX events as output for portlets is that the
portal is guaranteed to recieve XML-complaint output and may very
efficiently post-process/filter the output. It also allows multi-threaded
content generation (1 thread/portlet).
* If you wonder why the DataPortlet may be useful: suppose you have
on your page 4 MailPortlets each accessing a different mailbox, you may
very easily write a VirtualPortlet which post-process the data output of
these 4 portlets and creates a list of number of messages/account.
It also creates an additional caching control point (presentation
changed but content the same).
--
Raphaël Luta - [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]
