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 abstra
From: Gianugo Rabellino <[EMAIL PROTECTED]>
Date: Fri, 15 Jul 2005 10:29:03 +0200
On 7/14/05, Daniel Fagerstrom <[EMAIL PROTECTED]> 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
On 7/14/05, Daniel Fagerstrom <[EMAIL PROTECTED]> 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. Bein
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
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
Gianugo Rabellino wrote:
On 7/14/05, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
Michael Wechner 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 meta
On 7/14/05, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
> Michael Wechner 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 wr
Michael Wechner 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 T
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=10578281593&r=1&w=2
In a word: backward compatibility.
Wow, 2 years ago! And what about starting a rea
Gianugo Rabellino wrote:
On 7/13/05, Michael Wechner <[EMAIL PROTECTED]> 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
On 13.07.2005 23:38, Gianugo Rabellino wrote:
DirectoryGenerator extends TraversableGenerator
We've been through this before:
http://marc.theaimsgroup.com/?t=10578281593&r=1&w=2
In a word: backward compatibility.
Wow, 2 years ago! And what about starting a real migration now by
starti
On 7/13/05, Michael Wechner <[EMAIL PROTECTED]> 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 gen
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
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 ra
-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 sourc
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 n
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 l
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 lik
Forwarded from users list. If you need the whole thread read here:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106665805232126&w=2.
Joerg
Jorg Heymans wrote:
no prob. It shouldn't be a security problem because i have transformers
reading from shared drives as well.
I just stepped throug
Conal Tuohy wrote:
>>why not extend the mechanism of and
>>give a "FileInfoDirectoryGenerator" a prefix for a pipeline or resource,
>>that is calld on every found file.
>
>
> Yes I see your point. Maybe I've missed something, but I just wondered why
> this facility should be built into the genera
Hi Alfred
Alfred Fuchs wrote:
> > Conal Tuohy wrote:
> >
> > [...] Alternatively, if it really is necessary to call back
> > another pipeline, what about using a generic transformer like the
> > XIncludeTransformer?
>
> I will explain, what I want to do:
>
> (1) I have a website with a topic "
> Conal Tuohy wrote:
>
> [...] Alternatively, if it really is necessary to call back
another pipeline, what about using a generic transformer like the
XIncludeTransformer?
I will explain, what I want to do:
(1) I have a website with a topic "actual".
people should be able to upload HTML or (docbo
> Peter Hunsberger wrote:
> > Conal Tuohy <[EMAIL PROTECTED]> wrote:
> > string(/html/head/title[normalize-space()]|/html/body//h1[1])
> > The string() function returns the string value of the FIRST
> > NODE in the resulting nodeset.
>
> Ahh, that would do the trick. I believe in some old impl
Conal Tuohy <[EMAIL PROTECTED]> writes:
> Peter Hunsberger wrote:
>
> > Conal Tuohy <[EMAIL PROTECTED]> wrote:
> >
> > > Alfred Fuchs wrote:
> > >
> > > > in my expamle I extract the title of a HTML page in this way: if
> > > > exist and not empty, use it as title.
> > otherwise use
> > > >
Peter Hunsberger wrote:
> Conal Tuohy <[EMAIL PROTECTED]> wrote:
>
> > Alfred Fuchs wrote:
> >
> > > in my expamle I extract the title of a HTML page in this way: if
> > > exist and not empty, use it as title.
> otherwise use
> > > the first etc... this is logic, simply done in a xslt,
>
Conal Tuohy <[EMAIL PROTECTED]> wrote:
> Alfred Fuchs wrote:
>
> > in my expamle I extract the title of a HTML page in this way: if
> > exist and not empty, use it as title. otherwise use
> > the first etc... this is logic, simply done in a xslt,
> but hoe to
> > do this in a single xpath-
Alfred Fuchs wrote:
> in my expamle I extract the title of a HTML page in this way:
> if exist and not empty, use it as title.
> otherwise use the first etc...
> this is logic, simply done in a xslt, but hoe to do this in
> a single xpath-query?
string(/html/head/title[normalize-space()]|/html
> Why would you use a directory scanner separately?
because I already had a directoryscanner
(with a callbackhandler and the default callbackhandler writes xml to stdout :-)
and the algorithm (based on java.io.File and java.io.FileFilter)
is completely independent of other packages.
the benefit of
Alfred Fuchs wrote:
[extension to] DirectoryGenerator [...]
That's interesting. I guess, however, than that the best solution
would be patching the real DirectoryGenerator (in doing so please sync
the *TraversableGenerator in scratchpad too).
OK, but where should I post the patch?
Bugzilla (http:
[extension to] DirectoryGenerator [...]
That's interesting. I guess, however, than that the best solution would
be patching the real DirectoryGenerator (in doing so please sync the
*TraversableGenerator in scratchpad too).
OK, but where should I post the patch?
another question: I separated the
Alfred Fuchs wrote:
assume the directory-structure to scan is:
htmldir
hallo.html
emptydir
nomatchingdir
hallo.txt
the generator
produces this:
ups!
because, the include-pattern is also applied to directories.
That's interesting. I guess, however, than that the
Gianugo Rabellino wrote:
I made some changes to the
DirectoryGenerator (1)
and HTMLGenerator (4)
and introduced a PipelineDirectoryGenerator(2)
and FileInfoGenerator (3) for convenience.
my aim was to scan a directory for (Html,XML-)articles,
extract the titles from the files and show a overview s
Alfred Fuchs wrote:
hi,
hope, this is the right place to post.
I made some changes to the
DirectoryGenerator (1)
and HTMLGenerator (4)
and introduced a PipelineDirectoryGenerator(2)
and FileInfoGenerator (3) for convenience.
my aim was to scan a directory for (Html,XML-)articles,
extract the titl
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 SourceH
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
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
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 o
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 h
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
>
> 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 a
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 "^
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
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 orig
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"
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
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 b
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"
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
XPathTr
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 XP
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
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
> >>refa
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
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 X
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 que
53 matches
Mail list logo
