Note: The most interesting part of this mail is at the end.
> Micheal Rimov 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!
...
> <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?
We're currently looking into the service approach in detail. We may have
services for location, persistence of portlet settings, obtaining user
information, potentially others.
> > >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.
I didn't mean to imply that the customization descriptors should
necessarily be stored in files - storing them in databases should be an
option of course. Also, please note that what I posted here was only a
simple example to start a more detailed discussion - a more detailed
example with many good ideas has been posted by Raphael recently.
> 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.]
If I understand you correctly, you mean this:
Customization Customization
Descriptors in Descriptors Entries
Portlet Registry XML File in a Database
| |
+---------+ +---------+
| Portlet | or | Portlet |
+---+---------+-----------------+---------+-----+
| Portlet API |
+-----------------------------------------------+
|| ||
XML Cust. or Cust. Description Bean
Description created from XML Description
|| ||
\/ \/
+-----------------------------------------------+
| Portlet Customizer |
+-----------------------------------------------+
i.e. 4 Combinations of the following would be thinkable:
- Portlets getting info from XML File
- Portlets getting info from Database Entries
- Portlets passing Customization Description as Java Bean
- Portlets passing Customization Description as XML
The Customization Descriptor concept would be exposed though the
portlet APIs, Portlets would read the customization info and pass it.
I also think the envisioned customization mechanism should access the
portlet customization description via a well defined interface. This
interface needs not necessarily be the Portlet interface, another option
would be to define a provider interface within the portal, not as a part
of the Portlet API. The portlet customizer would access the available
portlet customization description provider - be it file based or using
a database - via the same description provider interface:
+-----------------------------------------------+
| Portlet Customizer |
+-----------------------------------------------+
| Portlet Cust.Description Provider Interface |
+-----------------+------+----------------------+
| File Based Impl | or | Impl. using Database |
+-----------------+ +----------------------+
| |
Customization Customization
Descriptors in Descriptor Entries
Portlet Registry XML File in a Database
The Portlet Customizer would pass a portlet ID to obtain the desired
CustomizationDescription Object.
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
--
--------------------------------------------------------------
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]
