cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: XObject
Date Fri, 01 Dec 2000 13:37:17 GMT

Paul Russell a écrit :
> On Thu, Nov 30, 2000 at 03:35:29PM +0000, Ross Burton wrote:
> > Paul Russell wrote:
> > > I'd rather not add a new directory just for XObject. Would it
> > > not make sense for it to be in either the 'xml' or 'util'
> > > packages? Since C1 doesn't have the 'xml' package, I guess
> > > there is sane, given the functionality the XObject provides.
> > > Thoughts?
> > I'm for deprecating C1 XObject, then creating a new XObject
> > org.apache.cocoon.xml.XObject with the new SAX2 methods and putting it
> > in C1 and C2.  Might upset some C1 users however...
> Yeah, ditto. How about this - we leave replace the existing
> XObject class in Cocoon1 with a proxy pointing to the new
> implementation, and whenever a method is called in the proxy,
> we print a message to the log/stderr (does C1 have logging?).
> Hopefully, that would remind/persuade people to move over to
> the new class ASAP.
> Thoughts?
> P.
> --
> Paul Russell                               <>
> Technical Director,         
> Luminas Ltd.

Nice idea, but XObject is an interface. To change it to a proxy, you
have to make it a class, thus inevitably breaking existing code. To
avoid that while preparing the C1->C2 transition, I think it's better to
have a new clean SAX2 compliant XObject (X2Object ?) and deprecate the
old one. This will warn current C1 users that they should migrate to
X2Object to be compatible with C2 while allowing them to keep their
current code unchanged if they want to stay with C1.

Also, the C2 <xsp:expr> tag does just a String.valueOf() of it's
content, whereas C1 has full set of overloaded methods to handle many
differing data types, including XObject. Why was it abandoned in C2 ?

Sylvain Wallez
Anyware Technologies

View raw message