>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.
> +1 +1 +1
:)
>+1. But we may need to differentiate between static init parameters set
the
>portal administrator and instance-defined parameters (for example those
set in
>the current PSML).
>
>If we start with this basic servlet-like API:
>
>interface Portlet {
>
> public void init( PortletConfig cfg );
>
> public void service( PortletRequest rq, PortletResponse rs );
>
> public void destroy();
>}
>
>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.
>> - PortletContext provides the portlet with access to the framework's
>> services. The context allows the portlet to store/retrieve information
>> and access information that the portlet requires to render itself.
>>
>
>+1 with the caveat above: how does a Portlet get its PortletContext ?
>
>> - UserProfile provides access to the user data.
>>
>> - Client represents the user's client device. It provides methods to get
>> manufacturer, model, user agent and check for capabilities.
>>
>> - Locator provides methods to determine the current location of a user's
>> device, e.g. longitude/latitude, country, state, city, ZIP code.
>>
>
>I don't think hooks should exist in a generic portlet API to cater for
this.
>Too biased towards mobile devices and probably not available on every
>implementation.
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.
>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.
>For me, a Portlet is basically a Servlet and JavaBeans/EJB mix.
>
>I would propose to handle customization by mandating Portlet to provide
>a descriptor file describing its operational parameters. The portal should
>provide a default UI implementation for entering parameters based on this
>descriptor but the Portlet may register a specific Customizer for handling
>complex needs.
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/>
>Comments ?
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
Raphael Luta <[EMAIL PROTECTED]> on 02.11.2000 15:22:43
Please respond to "JetSpeed" <[EMAIL PROTECTED]>
To: JetSpeed <[EMAIL PROTECTED]>
cc:
Subject: Re: Portlet API
[EMAIL PROTECTED] wrote:
>
> (Seems this mail did not get delivered, I hope you don't receive it
twice)
>
> It's good to see such a positive reaction on my first note about the
> need for a standard Portlet API and that such a live discussion started.
>
Great, I don't have to write this anymore... :)
> I guess we should go into more detail now. The figure below shows a
> portal that provides a Portlet API for portlets to make them independent
> of any specifics of the portal implementation (e.g. Turbine, ECS, Cocoon,
> for JetSpeed or something else for other portals).
>
> DB EJBs SOAP XML XML XML
> | | | | | |
> JSPs/Servlets Cocoon
> | |
> +-------+ +-------+
> |Portlet| ... |Portlet|
> +==========================================+
> | Portlet API |
> +==========================================+
> +--------------------+ +---------------------+
> DB --+ Persistence Service| | Location Service |
> +--------------------+ +---------------------+
> | Portal Framework |
> +--------------------+ +---------------------+
> LDAP-+ User Data Service | | Device Info Service |
> | +--------------------+ +---------------------+
> | +------------------------------------------+
> | | Rendering Engine |
> | | WML | HTML | VoiceXML | CHTML | ... | <- User PSML
> | +------+------+----------+-------+---------+
> | | Capability Detection/Rendering Selection |
> | +------------------------------------------+
> +---------| Authentication |
> +------------------------------------------+
> /\ ||
> || \/
> Request Response
>
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 ?
> We envision a standard Portlet API similar to the Servlet API, providing
> amongst others the following interfaces:
>
> - Portlet is used by the framework to invoke the portlet. Every portlet
> has to implement this interface.
>
+1
> - PortletRequest encapsulates the request to the portlet. It provides
> access to parameters/attributes, locator and client information, etc.
>
+1
> - PortletResponse encapsulates the response to the portlet.
>
+1
> - PortletConfig provides the portlet with config info used by the portlet
> as well as the framework to render the content.
>
+1. But we may need to differentiate between static init parameters set the
portal administrator and instance-defined parameters (for example those set
in
the current PSML).
If we start with this basic servlet-like API:
interface Portlet {
public void init( PortletConfig cfg );
public void service( PortletRequest rq, PortletResponse rs );
public void destroy();
}
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 )
> - PortletContext provides the portlet with access to the framework's
> services. The context allows the portlet to store/retrieve information
> and access information that the portlet requires to render itself.
>
+1 with the caveat above: how does a Portlet get its PortletContext ?
> - UserProfile provides access to the user data.
>
> - Client represents the user's client device. It provides methods to get
> manufacturer, model, user agent and check for capabilities.
>
> - Locator provides methods to determine the current location of a user's
> device, e.g. longitude/latitude, country, state, city, ZIP code.
>
I don't think hooks should exist in a generic portlet API to cater for
this.
Too biased towards mobile devices and probably not available on every
implementation.
> This is a preliminary, not-yet-complete list that we post to get early
> feedback from the JetSpeed community. Please let us know your comments!
>
> We also plan to submit a more detailled proposal soon.
>
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 ?).
For me, a Portlet is basically a Servlet and JavaBeans/EJB mix.
I would propose to handle customization by mandating Portlet to provide
a descriptor file describing its operational parameters. The portal should
provide a default UI implementation for entering parameters based on this
descriptor but the Portlet may register a specific Customizer for handling
complex needs.
Comments ?
--
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]
--
--------------------------------------------------------------
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]
