"Schwarz, Marcus" wrote:
> > >
> > > - 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.
>
My point was just that such a capability should not appear in a Portlet API
directly. Providing a service lookup method in the PortletContext and
defining a generic Location service API is fine, as long as implementing such
an API is not mandatory netither for Portlets nor for Portals. Some
Portals may only wish to cater for PC clients and should not be imposed an
increased complexity.
> >
> > 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.
>
OK
--
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]
