cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: [RT] Alternative Solution to XSP
Date Thu, 21 Jun 2001 21:25:06 GMT
On Thu, 21 Jun 2001, Berin Loritsch wrote:

> Personally, I don't like seeing alot of namespaces in my documents.
> This is one of the reasons I try to avoid XSP whenever possible.
> Also, many developers aren't going to want to write alot of Transformers.
> Remember one of the main benefits of XSP is immediate gratification.
> A new Generator was created and installed without restarting the web server.
> With the transformer approach, we have to restart the web server everytime
> we add a new class.  This isn't the way to go either.

i think i disagree with you on these points:

* lots of namespace declarations can be messy, but it's a pretty good way
to associate dynamic tags with the classes responsible for evaluating

* your argument against using transformers to do the job currently handled
by xsp logicsheets is invalid - you also have to restart the web server to
add a new xsp logicsheet! under my proposed scheme, you can still add
pages with dynamic elements to the system without having to restart the
web server, just like with xsp pages. it's only if you add a new dynamic
element handler (transformer) to the system that you'd need to restart the
web server.

* developers don't like writing xsp logicsheets _or_ transformers. :) true
enough. what about if we came up with a simple api to handle the common
case where people want to transform input consisting of a single dynamic
element (e.g. <my:get-clients/>) into something else (as compared to, say,
esql which operates on an entire input tree). then they could write
classes which conform to a simple API:

public interface NamespaceHandler {

  public void handleElement(String name, Attributes attributes,
ContentHandler handler) throws SAXException;


that's much easier to cope with than a full-blown Transformer.

> What we need is a way to dynamically react to business oriented markup.
> I am not sure what that way is right now.  I am wanting to explore solutions
> that other people have come up with though.

me too.

- donald

To unsubscribe, e-mail:
For additional commands, email:

View raw message