> -----Original Message-----
> From: Raphael Luta [mailto:[EMAIL PROTECTED]]
> Sent: Donnerstag, 2. November 2000 06:23
> To: JetSpeed
> Subject: Re: Portlet API
>
>
> [EMAIL PROTECTED] wrote:
> >
> > (Seems this mail did not get delivered, I hope you don't
> receive it twice)
> >
....
>
> > - 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.
On the other hand we surely need a way to provide this information to the
portlet. Regarding to your question above the need of the device-specific
info depends on the way to portlet is handling it's context to the
framework.
If it is handling optimized data we have to take care about devices.
An easy way to access the info about the current user should be available in
most frameworks. As soon as authentication/authorization is available this
should also be available in the framework and it's clearly helpful in the
portlet. If the portlet is not directly connected to the UM, we have to
provide
this info via an interface. The same is true for localization.
Maybe we should provide something like a capability-map of the framework,
with
which a portlet can discover the capabilities of the underlying
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 ?).
>
> 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.
>
+1. In some cases like stocks the portal should store the parameters and
also
provide an generic UI (which can be more or less controlled by the portlet).
But full-blown applications surely brings in complex UI's, which should be
registered in the framework.
Marcus
--
--------------------------------------------------------------
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]
