"Thomas F. Boehme" wrote:
Santiago, Raphael,
What's wrong with doing the things you suggested in a derived portlet?
Because the stream is the final result you can map (virtually) any other
method like SAX, DOM, ECS, etc to the stream. This way the interface is not
complicated any further, and portlet container writers are not burdened with
several implementation paths.
Also, doing this in derived portlets, mean we can easily add other mechanism
including Cocoon2 (so I think), without any modifications to the API! Sounds
very appealing to me
Doing this with a derived portlet is a big performance hit for implementations
that would process natively SAX events (for example Cocoon) because you would
have a event - byte streem - event serialization/parse process which is a
complete waste of resources.
In any case, the dual implementation paths is very easy to deal with since you
just have to convert the stream you don't want to deal with into the stream
you're intersted (that means either parsing the byte stream or serializing the
event stream).
Jetspeed 1.3 implementation will certainly use the byte stream path because
it's a natural fit with Turbine and Velocity but if I ever want to write an
alternate implementation, I don't want to be constrained by the API just
because it was optimized for one specific implementation.
I disagree with your assumption that 80% of the portlet markup needs to
parsed anyway. If that were so something is fundementally wrong. At any
rate, Jetspeed 1.3a1 does not parse any of its generated markup for whatever
reason, and it does what it is supposed to do.
My assumption is that for about 80% of the requests, the portal will need
to post-process the portlets output.
Jetspeed 1.3a1 does post-process the markup but is very poor at providing a stable
portlet environment: any portlet can competely screw the entire portal page
and I don't even speak about WML support where the portlets need to make
assumptions on the controls/controllers used in order to provide valid markup.
Don't tell me this is good, reliable and solid design.
I don't understand what really bothers you in adding the additional methods in
the PortletResponse :
- the additionnal implementation constraints are minimal
- it does not influence the performance of native byte stream implementations
- it broadens the scope of the API since it makes it more efficient on some
possible platforms
So what's the issue ?
--
Raphal Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
