cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <p...@luminas.co.uk>
Subject Re: XObject
Date Mon, 04 Dec 2000 13:04:31 GMT
On Mon, Dec 04, 2000 at 12:35:45PM +0000, Jeremy Quinn wrote:
> OK, but there are probably more core developers than logicsheet writers :)

Heh. True. Hopefully that won't persist forever ;)

> So, if someone uses org.apache.cocoon.framework.XObject, in Cocoon 1 it
> will still work. If they use it with Cocoon 2 they will get
> compilation/depreciation errors on their XSP, is that not clear enough?

Yep.

> Maybe the code for Cocoon 2 that handles XObject can issue a polite warning ?

I'd rather not, to be honest, because we'd end up with a package
with one class in it, which was kind of what we were trying to
avoid in the first place. I think if we spout warnings to the
log in Cocoon1 for the next month or so, people will at least be
aware that there's a problem, and will hopefully move over earlier
rather than leaving it until Cocoon2 is the current release.

To summarise:

* C1
 - org.apache.cocoon.framework.XObject (Deprecated -- warnings
    issued by the XSP engine if used)
 - org.apache.cocoon.xml.XObject (Current version)
* C2
 - *just* org.apache.cocoon.xml.XObject

> Sorry, I would -1 XObject2, just don't like names like that :<

Ditto. Object names are not version numbers.

> How about something like XInterface, XHandler, XSPObject?

Hmm. XMLFragment, XMLFragmentProducer?

> Comments anyone?
> Ricardo, are you lurking?

Indeed...


P.
-- 
Paul Russell                               <paul@luminas.co.uk>
Technical Director,                   http://www.luminas.co.uk
Luminas Ltd.

Mime
View raw message