Raphael Luta wrote:
> [EMAIL PROTECTED] wrote:
> > >
> > > - the portal can't easily guarantee that the aggregated result will
> > > display
> > > correctly on a given device because the markup generated by one
portlet
> > > may
> > > alter the markup of the whole page.
> >
> > Yes, to make it work, the portlets have to follow some guidelines
regarding
> > generated mark-up. We intend to write a "How-to-write-portlets Guide"
that
> > does
> > not only explain use of the API but also contains such guidelines for
> > generated
> > mark-up.
>
>
> I don't really believe in the effectiveness of guidelines, especially not
> when they're not enforceable: developpers are as good in following
> guidelines as they are in documenting their code ;/
Yes, guidelines only help those who follow to them. However, portlet
programmers who want their portlets to work well will probably follow
guidelines that help them make things work. (This doesn't help with
legacy pages that are not designed for use in portlets, though.)
> > > - the portlet writer has the responsability to implement all its
> > supported
> > > format. The portal administrator can't just add support for an
> > additionnal
> > > format without altering the portlet.
> > >
> > > - this may create problems with form handling because the portal
*needs*
> > to
> > > make sure there are no variable name collisions.
> >
> > 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.
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.
> > > I'd think the best way to design the API will be to first define a
> > generic
> > > Portlet API which require the Portlet to output a completely rendered
> > > content, and then create a sub-interface XMLPortlet (or DataPortlet
or
> > > whatever) that would provide additionnal entry points on the portlet
so
> > that
> > > the portal could query a portlet independently for either its "data"
> > output
> > > or its "layout" output.
> > >
> > > In any case, I believe we should always require the portlet to output
XML
> > > compliant markup, even if it's a already a layout markup (for
example
> > XHTML
> > > instead of HTML) so that if needed, the portal can easily
post-process
> > any
> > > output.
> > >
> > > I think this is flexible enough so that it'll not create a major
concern
> > > of portability.
> > >
> >
> > Sounds good. We are currently doing work on the generic Portlet API.
> > I'm looking forward to your ideas about the XMLPortlet.
> >
>
> XMLPortlet or whatever would be actually quite simple, something like:
>
> public interface XMLPortlet extends Portlet, ContentHandler {
>
> /*
> The content output by this method should be
> in a data markup
> */
> public void build( PortletRequest rq,
> PortletResponse rs,
> PortletContext ctx );
> }
>
> It may need to also extend LexicalHandler but I'm not sure.
>
> Of course, this construct implies that the generic Portlet
> outputs SAX events and the XMLPortlet may just act as both a
> XML SAX event producer as the Portlet and SAX event consumer so that
> it may itself transform its data markup in layout markup.
>
> So to make this work, we would need for example to define
> something like:
>
> interface PortletResponse {
>
> /** other methods */
>
> public ContentHandler getContentHandler();
>
> }
>
> In the case of the generic Portlet API, the Portal itself would
> register itself in the PortletResponse as recipient of the Portlet
> markup, whereas in the XMLPortlet case, the Portal may either
> register itself as the ContentHandler for the build() output if it
> knows how to deal with the data markup or else pipe the events
> back to the XMLPortlet for rendering.
>
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 ?
Best regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
Address: IBM Deutschland Entwicklung GmbH,
Schoenaicher Str. 220, 71032 Boeblingen, Germany
--
--------------------------------------------------------------
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]
