You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gianugo Rabellino <gi...@apache.org> on 2003/07/10 11:06:49 UTC
DirectoryGenerator source-oriented refactoring
I just added to scratchpad a refactored implementation of
DirectoryGenerator (TraversableGenerator) that doesn't work with just
files but with any TraversableSource. Together with it, a refactoring
was done on XPathDirectory, which is now XPathTraversable, so that even
XPath queries can be done on any TraversableSource (while we were at it,
we added namespace support, missing on the previous implementation).
Would you guys think that this implementation might supersede the
current DirectoryGenerator stuff, maybe by providing a migration path?
If so, I'd gladly produce some docs, confs and samples once it's proven
stable.
Also, since we're not talking about directory and files anymore, I used
the more generic terms of collection and resource, changing the
namespace too to "http://apache.org/cocoon/collection/1.0". I don't
remember if a vote was required for new namespace additions, but I'd
like to hear at least your opinion on that. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: DirectoryGenerator source-oriented refactoring
Posted by Upayavira <uv...@upaya.co.uk>.
On 10 Jul 2003 at 12:32, Sylvain Wallez wrote:
> And while we're at refactoring, what do you think of having separate
> regexps for directories and files ? This would be really useful since
> their respective naming rules are totally different. E.g. if I want
> only .xml files, the regexp has to be "^[^.]*$|\.xml$", which looks
> quite ugly when the file regexp would simply be "\.xml$".
Someone asked about that recently, and I think they were told that it wasn't needed.
But I think it is an obvious thing to add. I has always been a pain coming up with the
necessary regexp to include certain directories but include other files, all in a single
regexp.
Regards, Upayavira
Re: DirectoryGenerator source-oriented refactoring
Posted by Joerg Heinicke <jo...@gmx.de>.
Sylvain Wallez wrote:
>
> My cache implementation deals with SourceValidity instead of
> lastModified(), which allows caching for sources where lastModified
> isn't available (e.g. a CVS directory, or a tagged CVS source which can
> go back in time if the tag is moved). Also, I added a "directories-only"
> parameter which automatically filters regular files (it can be
> needlessly expensive to get infos on them and later discard them in the
> pipeline).
Ok, this would supercede the normal caching in any case, so the missing fix
on the caching key at the moment is not that problem.
> And while we're at refactoring, what do you think of having separate
> regexps for directories and files ? This would be really useful since
> their respective naming rules are totally different. E.g. if I want only
> .xml files, the regexp has to be "^[^.]*$|\.xml$", which looks quite
> ugly when the file regexp would simply be "\.xml$".
I wonder why RegExps?? Are they not to complicated for more specific stuff?
Wouldn't it be much easier to use the patterns used by Ant?
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
RE: DirectoryGenerator source-oriented refactoring
Posted by John Morrison <jo...@ntlworld.com>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Gianugo Rabellino wrote:
>
> > Sylvain Wallez wrote:
> >
> >> And while we're at refactoring, what do you think of having separate
> >> regexps for directories and files ? This would be really useful since
> >> their respective naming rules are totally different. E.g. if I want
> >> only .xml files, the regexp has to be "^[^.]*$|\.xml$", which looks
> >> quite ugly when the file regexp would simply be "\.xml$".
> >
> > How do you plan to express that in the component configuration? I'm
> > afraid it might start being overcomplicated...
>
> Simple : instead of the "includes" and "excludes" parameters, we would
> have "file-includes", "file-excludes", "dir-includes" and "dir-excludes".
>
> As decoupling files and dirs will drastically simplify the expressions,
> I like Joerg's proposal of using Ant-like wildcards, which would make
> them even more simpler.
>
> Thoughts ?
If it's to be generic, wouldn't something like leaves and nodes be better
than files and dirs?
I like the idea of the Ant-like wildcards (globbing?), but I'd wish to
retain the power of regex - could it be optional? Or have two generators
DirectoryGlobbingGenerator and DirectoryRegExGenerator?
J.
Re: DirectoryGenerator source-oriented refactoring
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Gianugo Rabellino wrote:
> Sylvain Wallez wrote:
>
>> And while we're at refactoring, what do you think of having separate
>> regexps for directories and files ? This would be really useful since
>> their respective naming rules are totally different. E.g. if I want
>> only .xml files, the regexp has to be "^[^.]*$|\.xml$", which looks
>> quite ugly when the file regexp would simply be "\.xml$".
>
>
> How do you plan to express that in the component configuration? I'm
> afraid it might start being overcomplicated...
Simple : instead of the "includes" and "excludes" parameters, we would
have "file-includes", "file-excludes", "dir-includes" and "dir-excludes".
As decoupling files and dirs will drastically simplify the expressions,
I like Joerg's proposal of using Ant-like wildcards, which would make
them even more simpler.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: DirectoryGenerator source-oriented refactoring
Posted by Gianugo Rabellino <gi...@apache.org>.
Sylvain Wallez wrote:
>
> My cache implementation deals with SourceValidity instead of
> lastModified(), which allows caching for sources where lastModified
> isn't available (e.g. a CVS directory, or a tagged CVS source which can
> go back in time if the tag is moved). Also, I added a "directories-only"
> parameter which automatically filters regular files (it can be
> needlessly expensive to get infos on them and later discard them in the
> pipeline).
>
> But my implementation started from the 2.0 DirectoryGenerator which
> hasn't all the fancy sort stuff. So I think a merge is actually what's
> needed.
Be my guest. ;-) If I can be of any help, just let me know.
> And while we're at refactoring, what do you think of having separate
> regexps for directories and files ? This would be really useful since
> their respective naming rules are totally different. E.g. if I want only
> .xml files, the regexp has to be "^[^.]*$|\.xml$", which looks quite
> ugly when the file regexp would simply be "\.xml$".
How do you plan to express that in the component configuration? I'm
afraid it might start being overcomplicated...
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: DirectoryGenerator source-oriented refactoring
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Gianugo Rabellino wrote:
> Sylvain Wallez wrote:
>
>>> I just added to scratchpad a refactored implementation of
>>> DirectoryGenerator (TraversableGenerator) that doesn't work with
>>> just files but with any TraversableSource. Together with it, a
>>> refactoring was done on XPathDirectory, which is now
>>> XPathTraversable, so that even XPath queries can be done on any
>>> TraversableSource (while we were at it, we added namespace support,
>>> missing on the previous implementation).
>>
>>
>> Damn, competing implementations : I've had this same thing on my HD
>> for several weeks now as part of the new version of the CVSSource.
>> Shame on me, I should have committed this for a long time. "release
>> early, release often".
>
>
> Oh well... silly me for not asking. :-)
>
>> My version is cacheable, but doesn't support XPath. I'll look at
>> yours to see how to merge them.
>
>
> Ours is cacheable too, actually it was very little more than
> s/File/Source on the cacheable DirectoryGenerator, so a more clever
> implementation would be most welcome. :-) Also, the XPath stuff is on
> an different class (XPathTraversableGenerator), which extends
> TraversableGenerator, so some care should be taken in merging the two.
My cache implementation deals with SourceValidity instead of
lastModified(), which allows caching for sources where lastModified
isn't available (e.g. a CVS directory, or a tagged CVS source which can
go back in time if the tag is moved). Also, I added a "directories-only"
parameter which automatically filters regular files (it can be
needlessly expensive to get infos on them and later discard them in the
pipeline).
But my implementation started from the 2.0 DirectoryGenerator which
hasn't all the fancy sort stuff. So I think a merge is actually what's
needed.
And while we're at refactoring, what do you think of having separate
regexps for directories and files ? This would be really useful since
their respective naming rules are totally different. E.g. if I want only
.xml files, the regexp has to be "^[^.]*$|\.xml$", which looks quite
ugly when the file regexp would simply be "\.xml$".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: DirectoryGenerator source-oriented refactoring
Posted by Gianugo Rabellino <gi...@apache.org>.
Sylvain Wallez wrote:
>> I just added to scratchpad a refactored implementation of
>> DirectoryGenerator (TraversableGenerator) that doesn't work with just
>> files but with any TraversableSource. Together with it, a refactoring
>> was done on XPathDirectory, which is now XPathTraversable, so that
>> even XPath queries can be done on any TraversableSource (while we were
>> at it, we added namespace support, missing on the previous
>> implementation).
>
> Damn, competing implementations : I've had this same thing on my HD for
> several weeks now as part of the new version of the CVSSource. Shame on
> me, I should have committed this for a long time. "release early,
> release often".
Oh well... silly me for not asking. :-)
> My version is cacheable, but doesn't support XPath. I'll look at yours
> to see how to merge them.
Ours is cacheable too, actually it was very little more than
s/File/Source on the cacheable DirectoryGenerator, so a more clever
implementation would be most welcome. :-) Also, the XPath stuff is on an
different class (XPathTraversableGenerator), which extends
TraversableGenerator, so some care should be taken in merging the two.
>> Also, since we're not talking about directory and files anymore, I
>> used the more generic terms of collection and resource, changing the
>> namespace too to "http://apache.org/cocoon/collection/1.0". I don't
>> remember if a vote was required for new namespace additions, but I'd
>> like to hear at least your opinion on that. :-)
>
> I think we should keep the current namespace, which describes a
> hierarchy, and is not really tied to the fact that is a real filesystem
> or something else. But we should keep the current DirectoryGenerator
> (eventually deprecated) since users may have extended it (we did it for
> an application to add extra attributes and filtering rules).
Makes sense.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: DirectoryGenerator source-oriented refactoring
Posted by Joerg Heinicke <jo...@gmx.de>.
Sylvain Wallez wrote:
> But we should keep the current DirectoryGenerator
> (eventually deprecated) since users may have extended it (we did it for
> an application to add extra attributes and filtering rules).
We don't have a beta out. So what about doing this change /now/? Make TG
renamed to SourceHierarchyG or CollectionG (a bit to generic IMO :) ) or
whatever default and deprecate DG and subclasses.
So 3 open issues I think:
1. namespace: old or new one?
2. name of the generator
3. when doing the change?
What are your thoughts?
Joerg
Re: DirectoryGenerator source-oriented refactoring
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Gianugo Rabellino wrote:
> I just added to scratchpad a refactored implementation of
> DirectoryGenerator (TraversableGenerator) that doesn't work with just
> files but with any TraversableSource. Together with it, a refactoring
> was done on XPathDirectory, which is now XPathTraversable, so that
> even XPath queries can be done on any TraversableSource (while we were
> at it, we added namespace support, missing on the previous
> implementation).
Damn, competing implementations : I've had this same thing on my HD for
several weeks now as part of the new version of the CVSSource. Shame on
me, I should have committed this for a long time. "release early,
release often".
My version is cacheable, but doesn't support XPath. I'll look at yours
to see how to merge them.
> Would you guys think that this implementation might supersede the
> current DirectoryGenerator stuff, maybe by providing a migration path?
> If so, I'd gladly produce some docs, confs and samples once it's
> proven stable.
>
> Also, since we're not talking about directory and files anymore, I
> used the more generic terms of collection and resource, changing the
> namespace too to "http://apache.org/cocoon/collection/1.0". I don't
> remember if a vote was required for new namespace additions, but I'd
> like to hear at least your opinion on that. :-)
I think we should keep the current namespace, which describes a
hierarchy, and is not really tied to the fact that is a real filesystem
or something else. But we should keep the current DirectoryGenerator
(eventually deprecated) since users may have extended it (we did it for
an application to add extra attributes and filtering rules).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: DirectoryGenerator source-oriented refactoring
Posted by Gianugo Rabellino <gi...@apache.org>.
Gianugo Rabellino wrote:
> Sylvain Wallez wrote:
>>> Weird. I still don't have any diffs from a cvs diff on the file, and
>>> yes, my version is 1.4. Sylvain: do you want me to sync it before
>>> trying to merge?
>>
>> Yes, please do so.
>
> OK, will do. Sorry for the inconvenience.
>
Done. Please crosscheck and start playing. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: DirectoryGenerator source-oriented refactoring
Posted by Gianugo Rabellino <gi...@apache.org>.
Sylvain Wallez wrote:
>>
>> Weird. I still don't have any diffs from a cvs diff on the file, and
>> yes, my version is 1.4. Sylvain: do you want me to sync it before
>> trying to merge?
>
>
>
> Yes, please do so.
OK, will do. Sorry for the inconvenience.
>Don't you have a sticky revision lying around ?
Oh well, "cvs status" tells me I don't. Time to check out the repo
again, I guess...
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: DirectoryGenerator source-oriented refactoring
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Gianugo Rabellino wrote:
> Joerg Heinicke wrote:
>
>> >> Nice job. A more generic solution is always useful.
>> >>
>> >> Unfortunately your implementations do not base on the latest *DG
>> >> stuff. E.g. I fixed the Caching key in the DG
>> >
>> >
>> > Uh? We did that yesterday, basing on the latest CVS version of the
>> DG.
>> > As of now, I have no diffs on the original one, so I don't see
>> what is
>> > the latest version you are talking about...
>> >
>>
>> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/generation/DirectoryGenerator.java
>
>
>
> Weird. I still don't have any diffs from a cvs diff on the file, and
> yes, my version is 1.4. Sylvain: do you want me to sync it before
> trying to merge?
Yes, please do so. Don't you have a sticky revision lying around ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: DirectoryGenerator source-oriented refactoring
Posted by Gianugo Rabellino <gi...@apache.org>.
Joerg Heinicke wrote:
> >> Nice job. A more generic solution is always useful.
> >>
> >> Unfortunately your implementations do not base on the latest *DG
> >> stuff. E.g. I fixed the Caching key in the DG
> >
> >
> > Uh? We did that yesterday, basing on the latest CVS version of the DG.
> > As of now, I have no diffs on the original one, so I don't see what is
> > the latest version you are talking about...
> >
>
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/generation/DirectoryGenerator.java
Weird. I still don't have any diffs from a cvs diff on the file, and
yes, my version is 1.4. Sylvain: do you want me to sync it before trying
to merge?
>> That's a matter of taste: while it's not real Xpointer, I liked the
>> idea of having the path in the URI, which allows me, e.g., to build
>> the source URI *and* the XPath from other pipeline steps (say an XSL
>> stylesheet).
> In which way? Generating a sitemap by XSL?
Not the sitemap, just the parameter of the src attribute, which can
easily be dynamically built. True, you can easily build the parameter
too, but still I like the ability of having it on the query too.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: DirectoryGenerator source-oriented refactoring
Posted by Joerg Heinicke <jo...@gmx.de>.
Gianugo Rabellino wrote:
> Joerg Heinicke wrote:
>
>> Nice job. A more generic solution is always useful.
>>
>> Unfortunately your implementations do not base on the latest *DG
>> stuff. E.g. I fixed the Caching key in the DG
>
>
> Uh? We did that yesterday, basing on the latest CVS version of the DG.
> As of now, I have no diffs on the original one, so I don't see what is
> the latest version you are talking about...
>
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/generation/DirectoryGenerator.java
e.g.:
public Serializable getKey() {
StringBuffer buffer = new StringBuffer();
int len = this.cacheKeyParList.size();
for (int i = 0; i < len; i++) {
buffer.append((String)this.cacheKeyParList.get(i) + ":");
}
return buffer.toString();
}
My latest commit is 7 days ago.
>> and changed the xpath handling from xpointer-ish (as it was written in
>> the docu; using #) to an extra parameter 'xpath' (Why let it look like
>> XPointer/XInclude, if it is not?).
>
>
> That's a matter of taste: while it's not real Xpointer, I liked the idea
> of having the path in the URI, which allows me, e.g., to build the
> source URI *and* the XPath from other pipeline steps (say an XSL
> stylesheet).
In which way? Generating a sitemap by XSL?
> I would say that we can go for a query string parameter if
> you really don't like the pound notation, but I'd really like to have
> that on the URL.
Not a query string, but a <map:parameter/>:
<map:generate type="xpathdirectory" src="docs/{1}">
<map:parameter name="xpath" value="/article/title|/article/abstract"/>
<map:parameter name="xmlFiles" value="\.xml$"/>
</map:generate>
(also 7 days old).
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: DirectoryGenerator source-oriented refactoring
Posted by Gianugo Rabellino <gi...@apache.org>.
Joerg Heinicke wrote:
> Nice job. A more generic solution is always useful.
>
> Unfortunately your implementations do not base on the latest *DG stuff.
> E.g. I fixed the Caching key in the DG
Uh? We did that yesterday, basing on the latest CVS version of the DG.
As of now, I have no diffs on the original one, so I don't see what is
the latest version you are talking about...
> and changed the xpath handling
> from xpointer-ish (as it was written in the docu; using #) to an extra
> parameter 'xpath' (Why let it look like XPointer/XInclude, if it is not?).
That's a matter of taste: while it's not real Xpointer, I liked the idea
of having the path in the URI, which allows me, e.g., to build the
source URI *and* the XPath from other pipeline steps (say an XSL
stylesheet). I would say that we can go for a query string parameter if
you really don't like the pound notation, but I'd really like to have
that on the URL.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: DirectoryGenerator source-oriented refactoring
Posted by Joerg Heinicke <jo...@gmx.de>.
Nice job. A more generic solution is always useful.
Unfortunately your implementations do not base on the latest *DG stuff. E.g.
I fixed the Caching key in the DG and changed the xpath handling from
xpointer-ish (as it was written in the docu; using #) to an extra parameter
'xpath' (Why let it look like XPointer/XInclude, if it is not?).
Joerg
Gianugo Rabellino wrote:
>
> I just added to scratchpad a refactored implementation of
> DirectoryGenerator (TraversableGenerator) that doesn't work with just
> files but with any TraversableSource. Together with it, a refactoring
> was done on XPathDirectory, which is now XPathTraversable, so that even
> XPath queries can be done on any TraversableSource (while we were at it,
> we added namespace support, missing on the previous implementation).
>
> Would you guys think that this implementation might supersede the
> current DirectoryGenerator stuff, maybe by providing a migration path?
> If so, I'd gladly produce some docs, confs and samples once it's proven
> stable.
>
> Also, since we're not talking about directory and files anymore, I used
> the more generic terms of collection and resource, changing the
> namespace too to "http://apache.org/cocoon/collection/1.0". I don't
> remember if a vote was required for new namespace additions, but I'd
> like to hear at least your opinion on that. :-)
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: DirectoryGenerator source-oriented refactoring
Posted by Upayavira <uv...@upaya.co.uk>.
On 10 Jul 2003 at 11:30, Gianugo Rabellino wrote:
> Upayavira wrote:
> > Gianugo,
> >
> >
> >>I just added to scratchpad a refactored implementation of
> >>DirectoryGenerator (TraversableGenerator) that doesn't work with
> >>just files but with any TraversableSource. Together with it, a
> >>refactoring was done on XPathDirectory, which is now
> >>XPathTraversable, so that even XPath queries can be done on any
> >>TraversableSource (while we were at it, we added namespace support,
> >>missing on the previous implementation).
> >
> >
> > I'm impressed. Well worth doing. I would certainly think that
> > replacing the DirectoryGenerator and XPathDirectory generator makes
> > sense. The only issue being one of how to maintain compatability.
>
> 1. The easy and unclean way: keep the old namespace and the
> directory/file metaphore (and maybe the class name too), just change
> the implementation to use TraversableSources instead than File;
Don't like.
> 2. The clean way: provide a clear documentation on what's changed and
> (maybe) add a stylesheet converting the "new" output to the "old" one.
I prefer that. The stylesheet sounds good.
> What's best is hard to tell. :-) Moreover, I'm definitely not sure
> that this should go into the next release, even if I consider it a
> major leap forward for collection browsing.
I think this sort of thing is worth doing, even if it is painful, because it makes our tools
much more generic.
I also think it might be worth leaving it in the scratchpad until after this release.
Also, could you tell us some of the TraversibleSources that you are using it with?
Regards, Upayavira
Re: DirectoryGenerator source-oriented refactoring
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Gianugo Rabellino wrote, On 10/07/2003 11.30:
...
> 1. The easy and unclean way: keep the old namespace and the
> directory/file metaphore (and maybe the class name too), just change the
> implementation to use TraversableSources instead than File;
>
> 2. The clean way: provide a clear documentation on what's changed and
> (maybe) add a stylesheet converting the "new" output to the "old" one.
3. Just make a new one with a different name. Java has still IO but can
also use NIO and JNDI...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: DirectoryGenerator source-oriented refactoring
Posted by Gianugo Rabellino <gi...@apache.org>.
Upayavira wrote:
> Gianugo,
>
>
>>I just added to scratchpad a refactored implementation of
>>DirectoryGenerator (TraversableGenerator) that doesn't work with just
>>files but with any TraversableSource. Together with it, a refactoring
>>was done on XPathDirectory, which is now XPathTraversable, so that
>>even XPath queries can be done on any TraversableSource (while we were
>>at it, we added namespace support, missing on the previous
>>implementation).
>
>
> I'm impressed. Well worth doing. I would certainly think that replacing the
> DirectoryGenerator and XPathDirectory generator makes sense. The only issue being
> one of how to maintain compatability.
1. The easy and unclean way: keep the old namespace and the
directory/file metaphore (and maybe the class name too), just change the
implementation to use TraversableSources instead than File;
2. The clean way: provide a clear documentation on what's changed and
(maybe) add a stylesheet converting the "new" output to the "old" one.
What's best is hard to tell. :-) Moreover, I'm definitely not sure that
this should go into the next release, even if I consider it a major leap
forward for collection browsing.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: DirectoryGenerator source-oriented refactoring
Posted by Upayavira <uv...@upaya.co.uk>.
Gianugo,
> I just added to scratchpad a refactored implementation of
> DirectoryGenerator (TraversableGenerator) that doesn't work with just
> files but with any TraversableSource. Together with it, a refactoring
> was done on XPathDirectory, which is now XPathTraversable, so that
> even XPath queries can be done on any TraversableSource (while we were
> at it, we added namespace support, missing on the previous
> implementation).
I'm impressed. Well worth doing. I would certainly think that replacing the
DirectoryGenerator and XPathDirectory generator makes sense. The only issue being
one of how to maintain compatability.
> Would you guys think that this implementation might supersede the
> current DirectoryGenerator stuff, maybe by providing a migration path?
> If so, I'd gladly produce some docs, confs and samples once it's
> proven stable.
> Also, since we're not talking about directory and files anymore, I
> used the more generic terms of collection and resource, changing the
> namespace too to "http://apache.org/cocoon/collection/1.0". I don't
> remember if a vote was required for new namespace additions, but I'd
> like to hear at least your opinion on that. :-)
Yup, namespace changes do require a vote. To my mind, the only thing needing
discussing is how to manage the transition from one component to the other,
minimising disruption for users.
Regards, Upayavira