[EMAIL PROTECTED] wrote:
>
><snip a lot of stuff>
>
> > >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.
>
I think all "interface" documentsor data structure defined with the API or
with Jetspeed should use an XML description. How these XML documents will
be stored and retrieved is an implementation issue and may depend on any
persistence method (database, flat file, ...).
> > 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 don't think portlet should be aware of their descriptor or even know how
to retrieve their cutomization properties. Let's not forget that we're
defining a generic interface which can be supported by many portal products
with very different capabilities.
> 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.
>
+1
--
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]
