Raphael Luta wrote:
> [EMAIL PROTECTED] wrote:
> >
> > I volunteer to put together a Portlet API Requirements
> > List that we can put on the web site. Please post your
> > requirements to the JetSpeed list with the topic
> > "Portlet API Requirements", and I'll include them in the
> > document.
> >
> > I'm looking forward to your input :)
> >
>
> Great. I've added some comments to some of your requirements
> in order to foster discussion and provide my own requirements
> at the end.
>
> > - The Portlet API should allow for definition of service
> > interfaces and for registration of services implementing
> > particular service interfaces, e.g.
> > - User info (for getting user info like name, address, age...)
> > - Persistence (for storing per-user, per-portlet settings)
> > - Location (for obtaining the user's location)
> > - Personalization (for storing/getting personalization info)
> > - Data (access to databases, schema-to-object mappings)
> > - Content (access to syndicated content)
> > - Cache (access to URLs via caches)
> > - ...
> >
> > Rationale: This allows to have a stable API core that can
> > be extended by services as required. Portals implementing
> > the Portlet API can provide implementations for a subset
> > of the services defined in the Portlet API.
> >
>
> I'm not sure what you're saying there:
> You want the Portlet API to provide a service lookup interface.
Yes.
> The definition of the real services interface would be external
> to the Portlet API.
Yes, the idea is to have a Portlet API and a set of additional
standard service interfaces for tasks like the ones listed above.
> No portal would be required to implement a given service.
> Correct ?
Yes. Each portal could decide which subset of services it wants
to provide and how they should be implemented. However, I expect
a persistence service and user info service would be provided by
virtually all portals, because they are necessary to allow
portlets to store settings and obtain info about the user in a
standard way.
> My own requirement not previously listed :
>
> - the Portlet API should allow only well-formed XML compliant
> output from the Portlet.
>
> Rationale: this would guarantee that the portal can always
> post-process the portlet output if needed and would prevent
> a portlet from breaking the display with a non well-formed
> output.
You mean XML, WML, XHTML, VoiceXML would be ok, but HTML with
missing end tags should not be generated ?
Is this really a requirement to the API or rather a requirement
for portlets to "behave well" by generating only well-formed XML ?
>It's the only one I can add right now.
>
>--
>Rapha�l Luta - [EMAIL PROTECTED]
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://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
