Alex McLintock wrote:
A portlet is an object, similar to a servlet, but which generates only a page "fragment". A portlet container would be in charge of providing them with a suitable Request, and combining the portlet response to compose the page that the browser will get. (And many more things...)At 17:41 21/01/03, you wrote:One more question: why not doing this as a subproject of JetSpeed ? It is an existing jakarta project, the scope matches - why creating a separate jakarta community instead of joining the existing one ?
I assume that it would be a tool which could be used by the Cocoon portal system, and a Struts portal system as well as Jetspeed which is essentially a Turbine portal system. People may want to use this component without using Jetspeed. Of course I haven't read the JSR yet.
Thus, it is not that simple. You will need a portlet container (which is what essentially is Jetspeed, a portlet container on top of Turbine).
During the discussions about the Portlet API proposal in the Jetspeed list, a couple of years ago, I positioned myself (I was not the only one), in a field that considered that we should have two kind of portlets:
- Stream based portlets (the original IBM proposal) which would use the response stream to write their content ("a la" JSP)
- SAX portlets, which would use a SAX pipeline to render the content.
I remember Raphael Luta was very concerned that any portlet should be a full XML document, because he also was very interested in XML transformations. See a pointer to part of the discussions, for those wanting some info.
http://www.mail-archive.com/[email protected]/msg05070.html
http://www.mail-archive.com/[email protected]/msg05026.html (joke on the "saxlet" word, that I still claim to have invented, not the concept, though :-(
I was rejected as a member of the JSP team, thus I don't know what they are doing in there. On a side note, by exactly the same reason I can speak freely about it. The discussion
But I'm quite sure that the only scalable way to have portlets that can be used from Cocoon (or any other XML based framework) will be those using SAX streams or plain XML (let's say DOM) to reder their content.
The reason is that portlets that generate a bytestream will need to be "re-parsed" by any XML-based portlet container, to transform them or serialize again at the end of the page rendering.
So, even if portlets are designed to be reusable from different frameworks (Struts, Turbine, Cocoon, etc.), Cocoon would have a nightmare re-parsing and re-serializing portlets if the SAXPortlet is not in the API. Both Turbine and Struts could, of course, use VelocityPortlets, JSPPortlets, and the like.
I'm currently interested in javax.portlet.sax.SAXPortlet ;-) (call them saxlets if you like it).
Regards,
Santiago
Alex Mc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
