Thomas,
I'll try to do this without having all of the details clear in my head.
First, there's the package hierarchy:
portlet
portlet.stream
portlet.sax
In the portlet package, there should be an interface to define the
contractual requirements of the child package methods. We could call this
PortletOutputInterface, or some such. It would need to define a method for
setting up the output stream to be used by the child
package: setupOutput(stream)
The portlet package would define the default implementation, implementing
the interface. This should be an abstract class. The classes in the child
packages need to subclass the abstract class or the interface.
The abstract class might then have a method called setupOutput() which
would look up the name of the method to invoke in order to dump the output
to the actual output stream (which is really the end result, no?). The
method name would be placed into a property somewhere (details tbd).
setupOutput() would then call the named method with a parameter of the
actual output stream. The method would be responsible for connecting the
back-end data source to the output stream.
portlet.stream would then write directly to the output stream. This would
be called directly from the portlet.
portlet.sax would have to complete the parsing of the DOM tree before
walking the tree, possibly transcoding it into another format, and finally
sending it to the output stream. This class would implement the necessary
callback hooks between it and the portlet to enable the parsing and event
handling required to convert the input source into a valid output stream.
That's my thinking, anyway, which is subject to change at this point. I've
got to do some digging into the existing packages to see what's being done
for the portlets before I can go any deeper on a possible
implemenation. Give me a day or two.
BTW, I'm working on the IBM Portal too.. with the Raleigh folks. I'll send
you an internal note so you'll have my address.
Steve
At 10:21 AM 2/19/2001 +0100, you wrote:
>Steve,
>
>Can you give an example of how such a stub should look like? You may indeed
>have good ideas here...
>
>Cheers,
>Thomas B.
>
>----- Original Message -----
>From: "Steve Freeman" <[EMAIL PROTECTED]>
>To: "JetSpeed" <[EMAIL PROTECTED]>
>Sent: Sunday, February 18, 2001 21:32
>Subject: Re: [vote] Portlet API - Summary and IBM Position (long)
>
>
> > At 07:36 PM 2/18/2001 +0100, you wrote:
> > >1.Primary output mode
> > > (This affects the programmatic Portlet API)
> > >
> > > Alternatives:
> > >
> > > a) output stream as base mode in portlet package
> > > sax as special mode in portlet.sax package
> > >
> > > b) neutral base interfaces in portlet package
> > > sax as special mode in portlet.sax package
> > > output stream as special mode in portlet.stream package
> > >
> > > c) sax as base mode in portlet package
> > > output stream as special mode in portlet.stream package
> > >
> > > Note: Whether or not portlets will run on all portlet
> > > containers does not depend on the primary output mode or the
> > > package structure of the API, but only on whether the
> > > specification defines all output modes as mandatory or not.
> > > When offering multiple output modes, the specification must
> > > mandate implementation of all of them by all portlet
> > > containers to assure portlet portability.
> >
> > Another alternative:
> >
> > Output in base portlet package as abstract stubs or an
> > interface. Both SAX and Stream as child packages portlet.sax
> > and portlet.stream, respectively. Set up the default mode
> > using a properties file.
> >
> > This will allow a more natural subclassing of output functions
> > which don't necessarily need to be based upon streams.
> >
> > Steve
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
