Mike,
This "philosophical thought train" is already on the go. Santiago's SAXlet
ideas go into the very same direction.
At the current stage, I am -1 on the idea, but that's mainly for lack for
examples. The nice thing about Santiago's approach is the fact that he still
wants to be open for the other types of portlets (I wouldn't call them
legacy, though). Having different types is not (only) a weakness, but it
allows you to say: "hey, why don't you write a portlet? It's easy because
you can use this and that method, and all the other ones too!" A JSP
portlet, for example, is an easy path for people who have done lots of web
app programming and have all the right tools at hand.
The problem I see with SAXlets or any related idea, is the lack of support
by tools and the limitation of flexibility. Agreed, flexibility comes with
some dangers, but together with tools support the benefits outweigh the
disadvantages.
Again, some examples may be shedding new light on this subject, not just for
me, but others too.
Cheers,
Thomas Boehme
----- Original Message -----
From: "Michael Rimov" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 08, 2000 01:19
Subject: Portlet API - Regarding Different Porlet Types
> Hello All!
>
> This is a more philisophical thought train on the overall design of the
> Portlet API:
>
> I think that one of the weaknesses of the Jetspeed implementation is that
> you have all these different portlet types depending on the type of
content
> that the portlet is actually dealing with. (And its not even dependant
> upon the final information the portlet is rendering) [Example: Cocoon
> portlet vs RSS portlet, vs JSP portlet etc. etc.]
>
> Instead of throwing all these portlet types for every content type, why
> don't we have a processing pipeline that would take care of the basic
> download / transformation, etc. We then would have to set up the generic
> portlet API to be independent of the actual data returned, but have
> attributes to allow the portlet container to figure out what it needs to
do
> with the data returned.
>
> Any thoughts on this? I'll be more than happy to start coming up with
some
> concrete examples, but I'd really like to know if people are interested in
> exploring this possibility first.
>
> Thanks,
> -Mike
>
>
>
> --
> --------------------------------------------------------------
> 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]
>
>
--
--------------------------------------------------------------
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]
