cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <rica...@apache.org>
Subject XSP Backwards
Date Wed, 24 May 2000 14:32:53 GMT
Hi guys,

Cocoon2's XSP implementation, being SAX-based and somewhat retouched,
isn't backwards compatible with its DOM-based, Cocoon1 sibling...

The new XSP design allows for "pluggable" markup and programing
languages. I'm extending this framework to also
accommodate pluggable hosting environments (e.g., servlets, offline,
command-line, used-defined...)

We could easily leverage this to create a "new" markup language called,
say, "dom-xsp" that simply wraps the (unchanged) previous version and
blindly spits SAX events from the generated DOM document.

Yes, this imposes some additional overhead but it also provides an easy
way to support existing code while users migrate to a SAX-based world.

I'm fairly confident this can be done with relatively little effort and,
while not bullet-proof, would allow us to "port" most of the existing
DOM XSP codebase...

For this, though, we need to resurrect DOM support in Cocoon2.

We also need to restore access to the objects made available by the
underlying servlet execution environment. This has to be done anyway:
would any of you do without cookies or response redirection in Cocoon2?
Keep in mind XSP is being
further generalized to allow for "pluggable" host environments and their
associated object models, so this "resurrection" wouldn't compromise
Cocoon2's valued servlet
independence...

Last but not least, the internal XSP code generation
mechanism is still DOM-based (and it's likely it remain so as
this representation appears to be more appropriate for this
purpose).

Therefore, I propose:

1) Restoring some of DOM's former first-class citizen status
   (at least in terms of parser support).
2) Wraping the previous, DOM-based version of XSP as a "new"
   markup language

Any ideas?

Mime
View raw message