[EMAIL PROTECTED] wrote:
>
> >I completely agree with this drawing (if I read it correctly that is):
> >in your portlet API view, is the Portlet responsible for rendering its
> >output in the device format or is it handled by the portal framework ?
> >if the Portlet does not do the rendering, what does it output ?
>
> Rapha�l,
>
> you read it right, I guess. Our view is that the portlet is responsible
> for rendering its output.
>
Yeah, that's what I thought but I can't say I like it :
if the portlet is responsible for generating its serialized output the
following statements are true :
- 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.
- 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.
- this does not promote reusability (all portlets will need to implement their
own output scheme)
Of course, if the portlet does not do the final device-dependent rendering
that creates a lot of additional issues.
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.
> >
> >If both admin-defined and user-defined parameters are set in PortletConfig
> >passed to the init() called, the portal engine needs as many portlet
> >instances running as there are different parameters value for a given
> portlet.
> >This doesn't scale very well for things like a RSSPortlet which takes its
> >URL as parameter...
> >
> >If the user-defined parameters are given the PortletRequest we mix 2
> >different information source within the same object (user-defined
> >parameters are stored locally and may be trusted, form/query parameters
> >should not be trusted) and we may prevent the portlet from doing
> >some optimization of resource.
> >
> >If the user-defined are accessible from the context and the context is
> >obtained by ServletConfig.getServletContext(), this is not thread-safe so
> we
> >still have one portlet instance/parameters set.
> >
> >I thought about adding an additionnal setConfig() call in the Portlet API
> >thus leaving the portal implementation to use any instanciation model they
> >like (SingleThread or multi-thread) and make sure their implementation is
> >thread-safe.
> >
> >Another way to do it is:
> >
> >public void service( PortletRequest rq, PortletResponse rs, PortletContext
> ctx )
>
> I know exactly what you mean. In the proposal we are currently working on,
> the
> portlet context is also passed as the third parameter of the service
> method, I
> think that's the way to go.
>
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);
>
> 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.
> >There's one additional very important thing to consider : customization.
> >How does a portal know what parameters can be set for a given Portlet ?
> >How do we build an UI for customization ? Should we let the Portlet
> >give us a specific UI for handling its customization (in case of complex
> >Portlets ?).
>
> Our approach for this is to let the portlets provide the UI and logic for
> their customization. Lets consider a stock quote portlet:
> 1. The Stock Quote Portlet is displayed on a portal page.
> 2. The user clicks the edit button.
> 3. A request like "..../PortletID=xyz&Action=Edit" is sent to the portal.
> 4. The portal resolves the portlet ID and passes the request to the
> appropriate portlet.
> 5. The portlet realizes that the edit mode is requested and e.g. invokes
> a JSP that displays a portlet specific form like this:
> ------------------------------------------
>
> PC WAP
> --------
> ARBA |X| | | |Remove|
> --------
> --------
> IBM |X| |X| |Remove|
> --------
> --------
> ICGE |X| | | |Remove|
> --------
>
> --------------------------- -----
> | | |Add|
> --------------------------- -----
>
> ------ --------
> |Save| |Cancel|
> ------ --------
> ------------------------------------------
> 6. The user inputs the desired settings and they are posted in a request
> like "..../PortletID=xyz&Action=Edit&Stocks=ARBA-1+IBM-1-2+ICGE-1"
> 7. The portlet realizes that it is still in edit mode, detects the
> parameters and stores them using the setAttribute method in the
> PortletContext.
>
You're still working on a "black box" model where the portlet
designer/programmer does most of the work and the framework has little
control point over the portlet functionality.
I understand that it's much easier to define and implement such an
API/framework but this may create some administrative/coherency issues
(if you have 30 portlets in your portal which comes from 30 different
"vendors" which all decided to implement a customization UI *their*
way...) and may prevent some UI optimizations from the portal
framework :
in your previous example :
imagine that a portal implementation forces the user to define
1 config PSML-like file per output format he wants to use (so he
has 1 HTML portal, 1 WML portal, etc...). There's no need in the
stock customization to mention the output format since there's
no choice available for this given implementation...
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.
>
> This is a great idea! We expect that most of the portlets we'll implement
> will require specific customization, but there will be a lot of cases were
> a customization descriptor will be very useful. An example might be an
> e-mail
> portlet:
>
> <CUSTOMIZATION DESCRIPTOR>
> <TITLE>E-mail Portlet Settings</TITLE>
> <ATTRIBUTE>
> <NAME>Mail Server Address</NAME>
> <TYPE>Text</TYPE>
> </ATTRIBUTE>
> <ATTRIBUTE>
> <NAME>User ID</NAME>
> <TYPE>Text</TYPE>
> </ATTRIBUTE>
> <ATTRIBUTE>
> <NAME>Password</NAME>
> <TYPE>Text</TYPE>
> </ATTRIBUTE>
> <CUSTOMIZATION DESCRIPTOR/>
>
I was thinking of something more complex:
<?xml version="1.0"?>
<portlet xmlns="http://java.apache.org/jetspeed/xml/PDML_1_0.xml"
xml:lang="en">
<!-- what am I talking about -->
<classname>org.apache.jetspeed.portlets.MailPortlet</classname>
<!-- some meta-info for user browsing -->
<title>Mail Portlet</title>
<description>
This portlet will allow you to retrieve
your mail headers from a mail store
</description>
<description xml:lang="fr">
Ce composant vous donne acc�s...
</description>
<!-- what portal service does the portlet require -->
<require service="Locator"/>
<!-- what client capabilities does the portlet require -->
<require capability="large_screen">
<!-- parameters description -->
<parameters>
<!-- standard user-settable parameter -->
<param name="mailhost" type="String" mandatory="yes">
<description>server host name</description>
<default>localhost</default>
</param>
<!-- constrainted user-settable parameter, each time
this param is set, a method will be called on
on the portlet to verify data integrity
-->
<param name="storetype" type="String" checked="yes"
mandatory="yes">
<description>Mail store type</description>
<default>IMAP4</default>
<!-- there should be a better markup to
provide choices -->
<choices>IMAP4,POP3</choices>
</param>
<!-- administrative only parameters -->
<param name="maxNumOfMail" type="Integer" hidden="yes">
<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.
--
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]
