Raphael,
> 1- I still believe it's a bery bad idea not to impose a binding output
> contract between the portlet and the container -> I'd like the API
> to only allow well-formed XML document output in order to
> make outpout post-processing as easy as possible (I thought last
> time we discussed this that the consensus was in implementing this
> restriction).
There certainly wasn't consensus on the issue of an output contract. I am
yet to see a convincing example of how such a contract should look like.
A small example would be enough. Well-formed XML is *not* the
answer to this particular problem. I am happy to repeat my 2 cents
of reasoning for this:
If the portal requires the portlet to adhere to a portal-set XML, then the
portlet is severely limited as to what content it can display. This approach
may well work for news-type content, but it is not general-purpose. You
can't apply the same DTD to news, wheather, mail, calendar, to-do, stock,
and you name it.
If on the other hand, the portal asks the portlet to return well-formed XML
according to a DTD that the portlet defines, it would also have to return
a number of stylesheets for processing. But who is saying that a portlet
that doesn't behave with raw markup, suddenly does so when providing
a stylesheet?
Apart from that, writing a stylesheet is more difficult than creating plain
markup. The argument you are giving for the bloated interface kind of
applies to this issue as well then.
Again, I am prepared to change my mind if someone can effectively
come up with a good contract. This is a challenge to you all! ;-)
But please refrain from commenting on this one if all you can add is
"it needs to be XML [because XML is hipp]".
It's time to move beyond this stage.
Cheers,
Thomas B.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
