Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of gianugo@gmail.com designates
 64.233.184.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=No2/iQAlA0S24YFv1LtUF27hljG4GHpEaAP9tjsfJ3op9lBanZGBhzXMAIeRLwhy6OAR0dZLjeB93lQM4Zb3uNdXkK0fn04zXdcF0okS3L76FeoIHAgShWTZGiYGEDXwByoQE7xaXfiKCOVvEMN2qlU2NtumDGO5Rf2ATSL8ikM=
Message-ID: <7557e99f0507150129513ce019@mail.gmail.com>
Date: Fri, 15 Jul 2005 10:29:03 +0200
From: Gianugo Rabellino <gianugo@gmail.com>
Reply-To: Gianugo Rabellino <gianugo@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: DirectoryGenerator using abstract Source
In-Reply-To: <42D63237.2000800@nada.kth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <42D44413.7080703@wyona.com> <42D52D22.3050902@wyona.com>
	 <db3g2i$an$1@sea.gmane.org> <42D5887E.4070502@wyona.com>
	 <7557e99f050713143818ece69e@mail.gmail.com> <42D58D9A.8050405@gmx.de>
	 <42D610D4.9080806@wyona.com> <loom.20050714T104052-848@post.gmane.org>
	 <7557e99f05071401596a700b0@mail.gmail.com>
	 <42D63237.2000800@nada.kth.se>

On 7/14/05, Daniel Fagerstrom <danielf@nada.kth.se> wrote:

> I don't think it is a good idea to deprecate things that have been
> arround in Cocoon from the very beginning and is part of about every
> book, tutorial and article that have been written about Cocoon.

I can clearly see your point. Being DG so much part of core Cocoon,
it's tough stuff to handle. However, it's also very clear how much TG
is more flexible: if you consider that a guy like Michi, a Cocoon and
Lenya committer, was unaware of its existence, you'll realize how
we're doing a very bad job in promoting our stuff, and how having
"old" stuff lying around stops the way to evolution and might become a
maintenance nightmare.
=20
> If they where considered harmfull in some way, hard to maintain or was
> in the way for developing new important stuff I would agree in
> deprecating them. But I don't see that it is the case.

Could well be. DG is solid stuff indeed, much like XSP who have been
there almost forever with little to no need for maintainance.

> A much better way to handle old stuff where we have found better ways of
> achieving what they are intended for is IMO doing like we did for XSP,
> remove it from core and move it to a block.
>=20
> For the DirectoryGenerator we could have a certain DirectoryGenerator
> block, or put it together with some other "obsololete" stuff that belong
> together in some way in a block. Or we could have an
> "backcompability2.1" block, with everything that we find old fashoned
> and want to move away from core.

I like that. It would be a nice way of migrating stuff. However, to
make it happen, we should make sure first that TG does everything DG
and relatives can do (images, Mp3, etc...).

> >In any case, avoid "extends" like the plague. If anything, the hassle
> >we're going to have because of that bunch of generators extending DG
> >should prove how extends can be harmful.
> >
> I don't follow you here, care to expand on it?

It's just the old fart of favoring composition over inheritance. This
stuff (taken from o.a.c.generation.ImageDirectoryGenerator) smells
Fragile Base Class:

    protected void setNodeAttributes(File path) throws SAXException {
        super.setNodeAttributes(path);
        [...]
    }

(wherever I see super(), I tend to frown :-)). I'd much rather see a
different pattern based on source descriptors and inspectors, much
like what has been done in the repository block with
InspectableSource, SourceDescriptor and SourceInspector.

Ciao,
--=20
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)