Raphael Luta 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.
> - 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'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.
> 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.
> >
> > Right, the Locator is something of particular interest for mobile
devices.
> > However, if loaction awareness is not covered by the Portlet API, there
> > will be no way to write location-aware portlets that runs on different
> > portals.
> > We'd like to make the Locator a property of PortletRequest. If a portal
or
> > the user's device is not location aware, getLocator() would just return
> > null.
> >
>
> Just implement a "portal service lookup" mechanism in the
PortletEnvironment
> (or PortletConfig) so that the Portlet can query the framework for any
> "locator" service.
> An additionnal Locator API can be proposed with the Portlet API.
> I view such a service as a "value added" optional framework capability
that
> the portlet may wish to take advantage of, but not as central to the
basic
> portal functionality as user authentication.
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.
> For simple case, a descriptor file along with some variable
> validation (a la JavaBean VetoableChange) shoule be used by the
> framework to construct homogenous UI for the user.
>
> However, for complex cases, the Portlet will have to provide its
> own customizer (or edit mode) because there'll be no easy way for
> the portal to deal with this.
I agree, we need both of these cases.
> 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">
> <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.
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]
