At 10:18 PM 11/2/2000 +0100, you wrote:
<snip> <snip>
> >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.
Agreed!
> >> - 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.
<disclaimer> I'm not a particularly hot designer.</disclaimer> :-)
The problem as I see with this method of going about it is that today it
will be WAP devices, but tomorrow it will be something totally different
that we'll be having to provide capabilities for, and I really would like
to keep the core API as stable as possible.
So what if we start providing a "PortalServices" interface that allows us
to plug in arbitrary services for which we define the actual abstract class
API for each service later as the need arises. In our specification we
will then have a list of optional services that a portlet container may
implement. So for a [very rough] pseudocode example we have:
interface PortalService { /*blah blah blah*/ }
class LocatorService implements PortalService { /*blah blah blah*/}
And then within the portlet we have:
LocatorService ls = (LocatorService)ctx.getService("Locator");
if (ls == null)
{
throw new Exception("Unable to locate an implementation of the
Locator Service");
}
Well, you get the idea.... (I hope :-) )
Anyway, I believe something along this line would allow us to keep the core
API pretty much intact, as well as allow people that want to play with
implementing a PortletContainer to do so without having to provide for a
batch of services they don't care about.
Any thoughts on this?
> >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.
I agree completely with this. I have a fairly nice "state-machine"
framework that I would be using for my own porlets and would prefer to be
not restricted by a standardized UI.
<snip> <snip>
> >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 ?
This might get a little hectic when you're talking about a system with a
batch of portlets. I could easily conceive of 30 or more configuration
files having to be maintained at any given time. In my case, I plan on
having all the my portlet-specific configuration information stored in a
central database. To give a little flexibility to the situation why don't
we have the portal query the portlet for the descriptor? If the descriptor
is an XML file, the portlet can feed the contents of the XML file to the
containing portal. In my case, I can query the database, create my own
in-memory XML to feed to the portal and send it on its way.
Or instead of just using XML to pass information to the containing portal,
we could have a Javabean that has a Vector of "attribute classes" as well
as standard properties that we want that we pass instead?
Wouldn't this be a bit more efficient, and by having vectors of attributes
in the beans, we could have something fairly extensible without the portal
container having to do a batch of parsing every time it wanted to know
about its portlets?
[Of course, the portlet could still have its own configuration stored in an
xml file which it then translates to the configuration bean, but in any
case, it gives us the flexibility of defining our own configuration
mechanisms.... we could even have the xml configuration descriptor as the
default implementation so portlet implementors wouldn't have to roll-their-
own each time.]
Thanks for letting me prattle. <grin>
-Mike
--
--------------------------------------------------------------
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]
