Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 74518 invoked from network); 4 Dec 2000 12:35:10 -0000 Received: from orion.uk.insnet.net (194.177.174.244) by locus.apache.org with SMTP; 4 Dec 2000 12:35:10 -0000 Received: from [192.168.0.2] ([213.38.161.125]) by orion.uk.insnet.net (8.9.3/8.9.3) with ESMTP id MAA14148 for ; Mon, 4 Dec 2000 12:35:06 GMT Mime-Version: 1.0 X-Sender: media@pop3.demon.co.uk Message-Id: In-Reply-To: <20001204114301.A1624@hydrogen.internal.luminas.co.uk> References: <3A2B66A0.EAB1568@anyware-tech.com> <20001204104722.B522@hydrogen.internal.luminas.co.uk> <20001204114301.A1624@hydrogen.internal.luminas.co.uk> Date: Mon, 4 Dec 2000 12:35:45 +0000 To: cocoon-dev@xml.apache.org From: Jeremy Quinn Subject: Re: XObject Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N 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: >> >Works for me, although there was talk of calling it XObject2 >> >or something to remove any chance of people being confused... >> For Cocoon 1, let's just bung some code into XSPPage.java where it checks >> to see if it has an XObject ..... >> It could become something like ..... >> // Convertible to DOM >> if (v instanceof org.apache.cocoon.xml.XObject){ >> DocumentFragment fragment = factory.createDocumentFragment(); >> ((org.apache.cocoon.xml.XObject) v).toDOM(fragment); >> return fragment; >> } >> if (v instanceof org.apache.cocoon.framework.XObject){ >> // issue depreciation warning, then output it anyway >> DocumentFragment fragment = factory.createDocumentFragment(); >> ((org.apache.cocoon.framework.XObject) v).toDOM(fragment); >> return fragment; >> } >> Does this help? > >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 :) 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? 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 :< How about something like XInterface, XHandler, XSPObject? Comments anyone? Ricardo, are you lurking? regards Jeremy -- ___________________________________________________________________ Jeremy Quinn Karma Divers webSpace Design HyperMedia Research Centre