[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.
>
> > +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.
>
If the business model of location-related services works well for mobile
devices, and I imagine it will, Phone companies will discover soon that they
could provide exactly the same kind of information for connections arriving
through POTS. Ditto for cable modems, ...
I think this could happen in the near future. Yahoo has already a service where
you need to key your address, and then they give you locations close to you,
like shops, pizza deliveries, etc.
But I agree that location services should be an optional service for any Portal
infrastructure.
>
> >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]
--
--------------------------------------------------------------
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]
