[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 ;/
> > - 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'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.
> > The tuple (request, response, context, + other stuff) is called
> Environment
> > in Cocoon 2 or RunData in Turbine.
> >
> > We could follow this pattern and define
> >
> > public void service(PortletEnvironment env);
>
> I'd prefer
>
> public void service(PortletRequest req, PortletResponse rsp,
> PortletContext context)
>
> as it is similar to the well-known Servlet API and exposes the request/
> response concept. The PortletEnvironment would contain both per-request
> info
> as well as more long-lived info, which might confuse portlet programmers.
>
I agree, on the other hand, using a wrapper object such as Environment
allows to add new methods or objects in the wrapper without altering
the base API. I'm +0 on either alternative.
>
> Conceptually, the location is an attribute of requests - the location may
> change over a sequence of requests originating from the same user, each
> request
> may contain different location info. Either the Location has to be a
> property
> of the PortletRequest or it must be obtained by passing a request to a
> locator
> service that parses the HTTP headers that contain the location info and
> returns
> a Location object with a standard interface. May be done like Micheal Rimov
> proposed ... we have to look into this some more.
>
Great.
> > I was thinking of something more complex:
> >
> > ...
> >
> > <param name="maxNumOfMail" type="Integer" hidden="yes">
>
> "hidden" may be misleading. You mean that this should be visible for
> users in the role "administrator", right ? What about something like
> <param name="maxNumOfMail" type="Integer" edit_role="Administrator"> vs
> <param name="maxNumOfMail" type="Integer" edit_role="User">
>
I agree that "hidden" is not very good but that was just an example out
of my mind. Introducing roles may add of lot of power but is more complex.
> > <description>
> > Maximum number of mails retrieved
> > </description>
> > <default>5</default>
> > </param>
> > </parameters>
> >
> > <!-- maybe other stuff missing -->
> > </portlet>
> >
> > Note that this allows the system administrator to determine what is
> > user-settable and should be hidden to user and set only by the site
> > administrator. This will allow to easily adapt a component
> > customization policy based on a site-wide policy.
> >
> > I think this discussion is very interesting, mainly because we have
> > 2 different point of views of the issue: you're dealing with it from
> > the portlet developper perspective, I'm mainly considering the portal
> > administrator point of view.
> >
> > Comments most welcome.
>
> As I understand, your proposal would be a Portlet Definition Markup
> Language (PDML) that allows to specify
> - Portlet class file
> - Portlet title and description
> - Services required by the portlet
> - Capabilities required by the portlet
> - Parameter descriptions including name, type, description, defaults,
> choices, and roles that allow editing/viewing.
> The PDML would be processed by a customization engine that uses the PDML
> param entries to create a form, sends it to the user's browser, receives
> the post request from the form and stores the settings.
>
> Very interesting ! With such a PDML it sould be possible to deploy portlets
> by providing a jar file with the code and a PDML file to the portal. The
> portal would process the PDML, install the code, and create the required
> admin and user forms for the parameters defined for the particular roles
> in the PDML. More complex portlets would have jar files that e.g. contain
> their own specific JSPs and appropriate logic for customization.
>
Yes, that's a good summary of the features I had in mind for the descriptor
(it basically is an extension of the current Jetspeed portlet registry
markup).
--
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]
