cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject Re: XObject
Date Mon, 04 Dec 2000 14:10:31 GMT
----- Original Message ----- 
From: "Jeremy Quinn" <>
To: <>
Sent: Monday, December 04, 2000 7:35 AM
Subject: Re: XObject

> At 11:43 +0000 04/12/00, Paul Russell wrote:
> >On Mon, Dec 04, 2000 at 11:13:33AM +0000, Jeremy Quinn wrote:
> >> At 10:47 +0000 04/12/00, Paul Russell wrote:
> >Yep. That's fine - understood that. I think the discussion was
> >more that having too classes called 'XObject' floating around
> >might confuse logic sheet writers, rather than core developers!
> >(Hey, we're already dealing with 23,000 lines of code - what's
> >another object between friends :)
> OK, but there are probably more core developers than logicsheet writers :)

Safe bet for now.

> 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?


If we automatically import the XObject in both versions of Cocoon, then the
logicsheet writers would have no reason to use the fully qualified class
name.  Why not take that approach, so the package that houses XObject shouldn't
matter to the Cocoon logicsheet developer?  They simply can't use the precompiled
XSP from one version in another.  If the API is the same, and the object is
already included--we don't need to have this discussion again when we move
from Cocoon 2 to Cocoon 3.

> Maybe the code for Cocoon 2 that handles XObject can issue a polite warning ?
> If this is not suitable, we have to change the name.
> Sorry, I would -1 XObject2, just don't like names like that :<

I absolutely agree.  Version numbers don't belong in object names.
You can implement the Avalon Version object in the API so that Cocoon can
differentiate between a Version 1.x XObject and a Version 2.x XObject
if that is deemed necessary (org.apache.avalon.blocks.Version).

> How about something like XInterface, XHandler, XSPObject?

XSPObject would be my vote :).

View raw message