You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Wechner <mi...@wyona.com> on 2005/07/13 00:28:35 UTC
DirectoryGenerator using abstract Source
Hi
It seems to me that the directory generator is not really based
on the "abstract methods" of an excalibur Source, but rather takes
the source and "maps" it onto a java.io.File.
Is that intended or just not implemented for the lack of time?
I would like to make this more generic with regard to other sources, e.g.
JCR or whatever. If this makes sense then I would patch the
DirectoryGenerator,
but otherwise I would write a "DirectoryGenerator" from scratch, e.g
CollectionGenerator which is making use the TraversableSource interface.
WDYT?
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: DirectoryGenerator using abstract Source
Posted by Michael Wechner <mi...@wyona.com>.
Joerg Heinicke wrote:
> On 14.07.2005 10:59, Gianugo Rabellino wrote:
>
>>
>>
>> 1. move TraversableGenerator to src/core,
>
>
> +1
+1
>
>> deprecate DirectoryGenerator leaving it untouched
>
>
> Read below.
>
>> 2. insert some log.xxx("DG is now deprecated, please use TG instead"),
>> where "xxx" is promoted from debug to error in a few release cycles
>>
>> 3. optionally start introducing XMLGenerator the same way (though the
>> only path I can foresee is via c&p)
>>
>> 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. Actually, it might be worth
>> thinking about refactoring the whole stuff using composition.
>
>
> Yeah, I know: "prefer composition over inheritance". And it might
> improve the DGs we have. But when we make DG extending TG just for a
> naming issue I see no advantage in composition and adding so many
> delegating methods.
>
> And why do you want to leave DG untouched at all? Couldn't TG do the
> same?
what implementing the DG XML syntax into TG if the Source is a "FileSource"?
>
> Regarding 3.: +1 for doing it the same way - what ever we will decide.
I think the name XMLGenerator is not very clear, although I have to admit
as was pointed out that ResourceGenerator is also not very clear. But
I think it would make sense to generalize it somehow anyway.
btw, I made a note within the javadoc of DirectoryGenerator pointing to
the TraversableGenerator
Michi
>
> Joerg
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: DirectoryGenerator using abstract Source
Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.07.2005 10:59, Gianugo Rabellino wrote:
> Don't want to rain on the party, but this has been exactly the kind of
> discussion that led nowhere a couple years ago.
Sorry for that ...
> I'm now convinced that
> File/DirectoryGenerator are there to stay, there is just too much
> stuff depending on it. Apart from naming issues (beware the bikeshed
> effect), my take would be:
>
> 1. move TraversableGenerator to src/core,
+1
> deprecate DirectoryGenerator leaving it untouched
Read below.
> 2. insert some log.xxx("DG is now deprecated, please use TG instead"),
> where "xxx" is promoted from debug to error in a few release cycles
>
> 3. optionally start introducing XMLGenerator the same way (though the
> only path I can foresee is via c&p)
>
> 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. Actually, it might be worth
> thinking about refactoring the whole stuff using composition.
Yeah, I know: "prefer composition over inheritance". And it might
improve the DGs we have. But when we make DG extending TG just for a
naming issue I see no advantage in composition and adding so many
delegating methods.
And why do you want to leave DG untouched at all? Couldn't TG do the same?
Regarding 3.: +1 for doing it the same way - what ever we will decide.
Joerg
Re: DirectoryGenerator using abstract Source
Posted by Guido Casper <gc...@s-und-n.de>.
Andrew Stevens wrote:
> By the way, what does the repository block (which contains the
> TraversableGenerator) do anyway? It's not mentioned in the list on the
> wiki at http://wiki.apache.org/cocoon/BlockDescriptions
Sorry for the late answer.
The repository block was once meant to contain abstractions to be used
with several kinds of repository implementations (like the Source
interface(s)) and additional components built on top of these
abstractions (like the TraversableGenerator).
The block now contains several more or less "parallel efforts" which in
part are somewhat stalled. I'm myself guilty of one of those and if I
don't find time to continue to work on it RSN I'll go for removing that
one from SVN to reduce confusion.
Guido
--
Freundliche Grüße / With kind regards
Guido Casper
S&N AG
Competence Center Open Source
Klingenderstr. 5
D 33100 Paderborn
voice +49 5251/1581-87
fax +49 5251/1581-71
eMail gcasper@s-und-n.de
Web http://www.s-und-n.de
Re: DirectoryGenerator using abstract Source
Posted by Andrew Stevens <at...@hotmail.com>.
>From: Gianugo Rabellino <gi...@gmail.com>
>Date: Fri, 15 Jul 2005 10:29:03 +0200
>
>On 7/14/05, Daniel Fagerstrom <da...@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,
If it was included in the user docs
(http://cocoon.apache.org/2.1/userdocs/generators/generators.html) then that
might help more people become aware of it...
I've noticed quite a few components which are included in the distribution
but not mentioned in those docs. I find that surprising since they look
like they are (or could be) generated directly from the sources.
By the way, what does the repository block (which contains the
TraversableGenerator) do anyway? It's not mentioned in the list on the wiki
at http://wiki.apache.org/cocoon/BlockDescriptions
Andrew.
Re: DirectoryGenerator using abstract Source
Posted by Gianugo Rabellino <gi...@gmail.com>.
On 7/14/05, Daniel Fagerstrom <da...@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.
> 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.
>
> 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,
--
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/)
Re: DirectoryGenerator using abstract Source
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Gianugo Rabellino wrote:
>On 7/14/05, Joerg Heinicke <jo...@gmx.de> wrote:
>
>
>>Michael Wechner <michael.wechner <at> wyona.com> writes:
>>
>>
>>>>Wow, 2 years ago! And what about starting a real migration now by
>>>>starting with the unclean way (DirectoryG extends TraversableG with
>>>>old namespace and directory/file metaphore as you wrote it),
>>>>deprecating it at the same time and making the TraversableG the
>>>>officially supported one?
>>>>
>>>>
>>>just one note re such a migration. Wouldn't it make sense to actually
>>>"rename" the TraversableGenerator to CollectionGenerator and introduce
>>>something like
>>>ResourceGenerator (or does that exist already?) and do
>>>
>>> DirectoryGenerator extends CollectionGenerator
>>> FileGenerator extends ResourceGenerator
>>>
>>>such that the terminology is consistent?
>>>
>>>
>>For the FileGenerator I have another name in mind since a long time:
>>XMLGenerator. This would make it consistent with HTMLGenerator and nearly any
>>else generator too. From where the XML is read is independent on the generator
>>itself, but only depends on the source provided via @src in sitemap. Having this
>>in mind ResourceGenerator is not the best name possible IMO and will continue
>>the irritating naming.
>>
>>
>
>Don't want to rain on the party, but this has been exactly the kind of
>discussion that led nowhere a couple years ago. I'm now convinced that
>File/DirectoryGenerator are there to stay, there is just too much
>stuff depending on it. Apart from naming issues (beware the bikeshed
>effect), my take would be:
>
>1. move TraversableGenerator to src/core, deprecate DirectoryGenerator
>leaving it untouched
>
>2. insert some log.xxx("DG is now deprecated, please use TG instead"),
>where "xxx" is promoted from debug to error in a few release cycles
>
>3. optionally start introducing XMLGenerator the same way (though the
>only path I can foresee is via c&p)
>
>
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.
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.
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.
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.
>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?
>Actually, it might be worth
>thinking about refactoring the whole stuff using composition.
>
>
So, what parts are you considering for the composition?
/Daniel
Re: DirectoryGenerator using abstract Source
Posted by Gianugo Rabellino <gi...@gmail.com>.
On 7/14/05, Joerg Heinicke <jo...@gmx.de> wrote:
> Michael Wechner <michael.wechner <at> wyona.com> writes:
>
> > > Wow, 2 years ago! And what about starting a real migration now by
> > > starting with the unclean way (DirectoryG extends TraversableG with
> > > old namespace and directory/file metaphore as you wrote it),
> > > deprecating it at the same time and making the TraversableG the
> > > officially supported one?
> >
> > just one note re such a migration. Wouldn't it make sense to actually
> > "rename" the TraversableGenerator to CollectionGenerator and introduce
> > something like
> > ResourceGenerator (or does that exist already?) and do
> >
> > DirectoryGenerator extends CollectionGenerator
> > FileGenerator extends ResourceGenerator
> >
> > such that the terminology is consistent?
>
> For the FileGenerator I have another name in mind since a long time:
> XMLGenerator. This would make it consistent with HTMLGenerator and nearly any
> else generator too. From where the XML is read is independent on the generator
> itself, but only depends on the source provided via @src in sitemap. Having this
> in mind ResourceGenerator is not the best name possible IMO and will continue
> the irritating naming.
Don't want to rain on the party, but this has been exactly the kind of
discussion that led nowhere a couple years ago. I'm now convinced that
File/DirectoryGenerator are there to stay, there is just too much
stuff depending on it. Apart from naming issues (beware the bikeshed
effect), my take would be:
1. move TraversableGenerator to src/core, deprecate DirectoryGenerator
leaving it untouched
2. insert some log.xxx("DG is now deprecated, please use TG instead"),
where "xxx" is promoted from debug to error in a few release cycles
3. optionally start introducing XMLGenerator the same way (though the
only path I can foresee is via c&p)
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. Actually, it might be worth
thinking about refactoring the whole stuff using composition.
Ciao,
--
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/)
Re: DirectoryGenerator using abstract Source
Posted by Joerg Heinicke <jo...@gmx.de>.
Michael Wechner <michael.wechner <at> wyona.com> writes:
> > Wow, 2 years ago! And what about starting a real migration now by
> > starting with the unclean way (DirectoryG extends TraversableG with
> > old namespace and directory/file metaphore as you wrote it),
> > deprecating it at the same time and making the TraversableG the
> > officially supported one?
>
> just one note re such a migration. Wouldn't it make sense to actually
> "rename" the TraversableGenerator to CollectionGenerator and introduce
> something like
> ResourceGenerator (or does that exist already?) and do
>
> DirectoryGenerator extends CollectionGenerator
> FileGenerator extends ResourceGenerator
>
> such that the terminology is consistent?
For the FileGenerator I have another name in mind since a long time:
XMLGenerator. This would make it consistent with HTMLGenerator and nearly any
else generator too. From where the XML is read is independent on the generator
itself, but only depends on the source provided via @src in sitemap. Having this
in mind ResourceGenerator is not the best name possible IMO and will continue
the irritating naming.
Joerg
Re: DirectoryGenerator using abstract Source
Posted by Michael Wechner <mi...@wyona.com>.
Joerg Heinicke wrote:
> On 13.07.2005 23:38, Gianugo Rabellino wrote:
>
>>> DirectoryGenerator extends TraversableGenerator
>>
>>
>> We've been through this before:
>>
>> http://marc.theaimsgroup.com/?t=105782815900003&r=1&w=2
>>
>> In a word: backward compatibility.
>
>
> Wow, 2 years ago! And what about starting a real migration now by
> starting with the unclean way (DirectoryG extends TraversableG with
> old namespace and directory/file metaphore as you wrote it),
> deprecating it at the same time and making the TraversableG the
> officially supported one?
just one note re such a migration. Wouldn't it make sense to actually
"rename" the TraversableGenerator to CollectionGenerator and introduce
something like
ResourceGenerator (or does that exist already?) and do
DirectoryGenerator extends CollectionGenerator
FileGenerator extends ResourceGenerator
such that the terminology is consistent?
Michi
>
> Joerg
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: DirectoryGenerator using abstract Source
Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.07.2005 23:38, Gianugo Rabellino wrote:
>>DirectoryGenerator extends TraversableGenerator
>
> We've been through this before:
>
> http://marc.theaimsgroup.com/?t=105782815900003&r=1&w=2
>
> In a word: backward compatibility.
Wow, 2 years ago! And what about starting a real migration now by
starting with the unclean way (DirectoryG extends TraversableG with old
namespace and directory/file metaphore as you wrote it), deprecating it
at the same time and making the TraversableG the officially supported one?
Joerg
Re: DirectoryGenerator using abstract Source
Posted by Michael Wechner <mi...@wyona.com>.
Gianugo Rabellino wrote:
>On 7/13/05, Michael Wechner <mi...@wyona.com> wrote:
>
>
>>Unico Hommes wrote:
>>
>>
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>Michael Wechner wrote
>>>I think it would make sense to make a
>>>note
>>>within the DirectoryGenerator that the TraversableGenerator exists and is
>>>more generic.
>>>
>>>In fact IMHO, it should be deprecated in favor of TraversableGenerator...
>>>
>>>
>>>
>>I didn't dare to suggest that ;-), but on the other hand I have to say,
>>that DirectoryGenerator sounds more "familiar" than TraversableGenerator,
>>but maybe one just wants to subclass it:
>>
>>DirectoryGenerator extends TraversableGenerator
>>
>>
>
>We've been through this before:
>
>http://marc.theaimsgroup.com/?t=105782815900003&r=1&w=2
>
>
ok, you were there 2 years ago where I am now ;-)
>In a word: backward compatibility.
>
>
you mean re XML output?
But we could at least deprecate it and point to the TraversableGenerator.
Michi
>Ciao,
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: DirectoryGenerator using abstract Source
Posted by Gianugo Rabellino <gi...@gmail.com>.
On 7/13/05, Michael Wechner <mi...@wyona.com> wrote:
> Unico Hommes wrote:
>
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Michael Wechner wrote
> > I think it would make sense to make a
> >note
> >within the DirectoryGenerator that the TraversableGenerator exists and is
> >more generic.
> >
> >In fact IMHO, it should be deprecated in favor of TraversableGenerator...
> >
> I didn't dare to suggest that ;-), but on the other hand I have to say,
> that DirectoryGenerator sounds more "familiar" than TraversableGenerator,
> but maybe one just wants to subclass it:
>
> DirectoryGenerator extends TraversableGenerator
We've been through this before:
http://marc.theaimsgroup.com/?t=105782815900003&r=1&w=2
In a word: backward compatibility.
Ciao,
--
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/)
Re: DirectoryGenerator using abstract Source
Posted by Michael Wechner <mi...@wyona.com>.
Unico Hommes wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Michael Wechner wrote
> I think it would make sense to make a
>note
>within the DirectoryGenerator that the TraversableGenerator exists and is
>more generic.
>
>
>
>
>In fact IMHO, it should be deprecated in favor of TraversableGenerator...
>
>
I didn't dare to suggest that ;-), but on the other hand I have to say,
that DirectoryGenerator sounds more "familiar" than TraversableGenerator,
but maybe one just wants to subclass it:
DirectoryGenerator extends TraversableGenerator
WDYT?
Michi
>- --
>Unico
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (Darwin)
>
>iD8DBQFC1UORcuec8tVNKAwRAiA4AJ94XDoBh0ACS2iTFW+uqTDcIBJ6lQCg34Fr
>xYZdDb1pyefSC/Wlf2FAyjw=
>=y0i0
>-----END PGP SIGNATURE-----
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: DirectoryGenerator using abstract Source
Posted by Andrew Franz <af...@optushome.com.au>.
Unico Hommes wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Michael Wechner wrote:
>
>
>>Joerg Heinicke wrote:
>>
>>
>>
>>>On 13.07.2005 00:28, Michael Wechner wrote:
>>>
>>>
>>>
>>>>It seems to me that the directory generator is not really based
>>>>on the "abstract methods" of an excalibur Source, but rather takes
>>>>the source and "maps" it onto a java.io.File.
>>>>
>>>>Is that intended or just not implemented for the lack of time?
>>>>
>>>>I would like to make this more generic with regard to other sources,
>>>>e.g.
>>>>JCR or whatever. If this makes sense then I would patch the
>>>>DirectoryGenerator,
>>>>but otherwise I would write a "DirectoryGenerator" from scratch, e.g
>>>>CollectionGenerator which is making use the TraversableSource interface.
>>>>
>>>>
>>>
>>>You don't have to:
>>>$COCOON_HOME/src/blocks/repository/java/org/apache/cocoon/generation/TraversableGenerator.java
>>>
>>>
>>>
>>
>>thanks very much for the pointer. I think it would make sense to make a
>>note
>>within the DirectoryGenerator that the TraversableGenerator exists and is
>>more generic.
>>
>>
>>
>
>In fact IMHO, it should be deprecated in favor of TraversableGenerator...
>
>- --
>Unico
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (Darwin)
>
>iD8DBQFC1UORcuec8tVNKAwRAiA4AJ94XDoBh0ACS2iTFW+uqTDcIBJ6lQCg34Fr
>xYZdDb1pyefSC/Wlf2FAyjw=
>=y0i0
>-----END PGP SIGNATURE-----
>
>
>
>
As a user, I found that DirectoryGenerator didn't do what I wanted, so I
went down the path of creating a variant of (not extending)
DirectoryGenerator essentially to show meta-information (using POIFS) of
MS-Office files and images (I also added ImageGenerator functionality
and added .png, .ico, .bmp).
Output looks like this:
<<dx:directory name="*poitest*" lastModified="*1120331938242*"
date="*7/3/05 5:18 AM*" size="*0*" sort="*name*" reverse="*false*"
requested="*true*">
- <#> <dx:file type="*application/msword*" name="*e2u.doc*"
lastModified="*1118747923320*" date="*6/14/05 9:18 PM*" size="*110080*">
<dx:doc title="" author="*rvanvuuren*" savedate="*6/14/05
10:20 AM*" />
</dx:file>
<dx:file type="*application/vnd.ms-visio*" name="*Servlet.vsd*"
lastModified="*998171376000*" date="*8/19/01 7:49 AM*" size="*96256*">
<dx:doc title="*Servlet*" author="*Roger Dodger*" />
</dx:file>
- <#> <dx:file type="*application/vnd.ms-powerpoint*"
name="*PPT1.ppt*" lastModified="*1116947798687*" date="*5/25/05 1:16
AM*" size="*11264*">
<dx:doc title="*Hello*" author="*Andrew Franz*" subject="*POI*"
savedate="*5/25/05 1:16 AM*" />
</dx:file>
< <dx:file type="*image/png*" name="*cocoon-mini.png*"
lastModified="*1118171481493*" date="*6/8/05 5:11 AM*" size="*299*">
<dx:image width="*80*" height="*15*" />
</dx:file>
</dx:directory>
Looking at TraversableGenerator, I saw a reference to an
'InspectableSource'. This seems a better way to go.
(As a user) Is there a way to achieve the same outcome using
TraversableGenerator and 'InspectableSource'?
(As a developer) Should I be extending 'InspectableSource' with POIFS or
am I better off sticking with a custom generator?
The end goal is to extract meta-info and include it in the directory
listing & then use Lucene to index the meta info - so a variety of file
types need to be 'inspected'
Re: DirectoryGenerator using abstract Source
Posted by Unico Hommes <un...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Wechner wrote:
> Joerg Heinicke wrote:
>
>> On 13.07.2005 00:28, Michael Wechner wrote:
>>
>>> It seems to me that the directory generator is not really based
>>> on the "abstract methods" of an excalibur Source, but rather takes
>>> the source and "maps" it onto a java.io.File.
>>>
>>> Is that intended or just not implemented for the lack of time?
>>>
>>> I would like to make this more generic with regard to other sources,
>>> e.g.
>>> JCR or whatever. If this makes sense then I would patch the
>>> DirectoryGenerator,
>>> but otherwise I would write a "DirectoryGenerator" from scratch, e.g
>>> CollectionGenerator which is making use the TraversableSource interface.
>>
>>
>>
>> You don't have to:
>> $COCOON_HOME/src/blocks/repository/java/org/apache/cocoon/generation/TraversableGenerator.java
>>
>
>
>
> thanks very much for the pointer. I think it would make sense to make a
> note
> within the DirectoryGenerator that the TraversableGenerator exists and is
> more generic.
>
In fact IMHO, it should be deprecated in favor of TraversableGenerator...
- --
Unico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFC1UORcuec8tVNKAwRAiA4AJ94XDoBh0ACS2iTFW+uqTDcIBJ6lQCg34Fr
xYZdDb1pyefSC/Wlf2FAyjw=
=y0i0
-----END PGP SIGNATURE-----
Re: DirectoryGenerator using abstract Source
Posted by Upayavira <uv...@odoko.co.uk>.
Michael Wechner wrote:
> Joerg Heinicke wrote:
>
>> On 13.07.2005 00:28, Michael Wechner wrote:
>>
>>> It seems to me that the directory generator is not really based
>>> on the "abstract methods" of an excalibur Source, but rather takes
>>> the source and "maps" it onto a java.io.File.
>>>
>>> Is that intended or just not implemented for the lack of time?
>>>
>>> I would like to make this more generic with regard to other sources,
>>> e.g.
>>> JCR or whatever. If this makes sense then I would patch the
>>> DirectoryGenerator,
>>> but otherwise I would write a "DirectoryGenerator" from scratch, e.g
>>> CollectionGenerator which is making use the TraversableSource interface.
>>
>>
>>
>> You don't have to:
>> $COCOON_HOME/src/blocks/repository/java/org/apache/cocoon/generation/TraversableGenerator.java
>>
>
>
>
> thanks very much for the pointer. I think it would make sense to make a
> note
> within the DirectoryGenerator that the TraversableGenerator exists and is
> more generic.
Seems fair. Please go ahead :-)
Regards, Upayavira
Re: DirectoryGenerator using abstract Source
Posted by Michael Wechner <mi...@wyona.com>.
Joerg Heinicke wrote:
> On 13.07.2005 00:28, Michael Wechner wrote:
>
>> It seems to me that the directory generator is not really based
>> on the "abstract methods" of an excalibur Source, but rather takes
>> the source and "maps" it onto a java.io.File.
>>
>> Is that intended or just not implemented for the lack of time?
>>
>> I would like to make this more generic with regard to other sources,
>> e.g.
>> JCR or whatever. If this makes sense then I would patch the
>> DirectoryGenerator,
>> but otherwise I would write a "DirectoryGenerator" from scratch, e.g
>> CollectionGenerator which is making use the TraversableSource interface.
>
>
> You don't have to:
> $COCOON_HOME/src/blocks/repository/java/org/apache/cocoon/generation/TraversableGenerator.java
thanks very much for the pointer. I think it would make sense to make a note
within the DirectoryGenerator that the TraversableGenerator exists and is
more generic.
Michi
>
>
> Joerg
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: DirectoryGenerator using abstract Source
Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.07.2005 00:28, Michael Wechner wrote:
> It seems to me that the directory generator is not really based
> on the "abstract methods" of an excalibur Source, but rather takes
> the source and "maps" it onto a java.io.File.
>
> Is that intended or just not implemented for the lack of time?
>
> I would like to make this more generic with regard to other sources, e.g.
> JCR or whatever. If this makes sense then I would patch the
> DirectoryGenerator,
> but otherwise I would write a "DirectoryGenerator" from scratch, e.g
> CollectionGenerator which is making use the TraversableSource interface.
You don't have to:
$COCOON_HOME/src/blocks/repository/java/org/apache/cocoon/generation/TraversableGenerator.java
Joerg