Hi,
A couple of comments about the directory scanner... 1. that would be fine to give the name of the scanner in the doc about this processor :-) ... 2. the configuration requires a path that is a URI while the output gives the paths as OS dependent paths. That's not very coherent and that complicates the job of applications that want to use the directory scanner recursively and build the next iteration's path in a configuration from the previous iteration's results (they need to translate from OS dependent paths to URIs). My suggestion would be to give both the OS dependent path and the URI in the output (eventually adding a config input for people who would prefer having only one of them). Thanks, Eric -- Le premier annuaire des apiculteurs 100% XML! http://apiculteurs.info/ ------------------------------------------------------------------------ Eric van der Vlist http://xmlfr.org http://dyomedea.com (ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax (W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema ------------------------------------------------------------------------ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Administrator
|
Eric van der Vlist wrote:
> Hi, > > A couple of comments about the directory scanner... > > 1. that would be fine to give the name of the scanner in the doc > about this processor :-) ... Do you mean mentioning "oxf:directory-scanner"? Thanks, that's now fixed. > 2. the configuration requires a path that is a URI while the output > gives the paths as OS dependent paths. That's not very coherent > and that complicates the job of applications that want to use > the directory scanner recursively and build the next iteration's > path in a configuration from the previous iteration's results > (they need to translate from OS dependent paths to URIs). My > suggestion would be to give both the OS dependent path and the > URI in the output (eventually adding a config input for people > who would prefer having only one of them). I think this only appears on the root element of the output, right? In that case there would be no serious drawback, from a memory / performance point of view, in providing both. I created an RFE for this: https://forge.objectweb.org/tracker/index.php?func=detail&aid=304256&group_id=168&atid=350210 -Erik -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Le lundi 07 novembre 2005 à 14:48 +0100, Erik Bruchez a écrit :
> Eric van der Vlist wrote: > > Hi, > > > > A couple of comments about the directory scanner... > > > > 1. that would be fine to give the name of the scanner in the doc > > about this processor :-) ... > > Do you mean mentioning "oxf:directory-scanner"? Yes, that's easy enough to guess since you are using the same naming policy for your different processors, but that's still better if people don't have to make guesses :-) ! > Thanks, that's now fixed. > > > 2. the configuration requires a path that is a URI while the output > > gives the paths as OS dependent paths. That's not very coherent > > and that complicates the job of applications that want to use > > the directory scanner recursively and build the next iteration's > > path in a configuration from the previous iteration's results > > (they need to translate from OS dependent paths to URIs). My > > suggestion would be to give both the OS dependent path and the > > URI in the output (eventually adding a config input for people > > who would prefer having only one of them). > > I think this only appears on the root element of the output, right? that appears also for each file : <file last-modified-ms="1101512191718" last-modified-date="2004-11-27T00:36:31.718" size="2410" path="initialization\init-script.xpl" name="init-script.xpl"/> > In > that case there would be no serious drawback, from a memory / > performance point of view, in providing both. I created an RFE for this: > > https://forge.objectweb.org/tracker/index.php?func=detail&aid=304256&group_id=168&atid=350210 Also (something I have found since my last mail), I don't want to start over the debate about exception handling, but think that it would be nice if there was an option to avoid that the directory scanner sends an exception when it isn't allowed to read one of the files (or sub directory) during its scanning. Thanks, Eric -- Have you ever thought about unit testing XSLT templates? http://xsltunit.org ------------------------------------------------------------------------ Eric van der Vlist http://xmlfr.org http://dyomedea.com (ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax (W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema ------------------------------------------------------------------------ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Administrator
|
Eric van der Vlist wrote:
> Also (something I have found since my last mail), I don't want to > start over the debate about exception handling, but think that it > would be nice if there was an option to avoid that the directory > scanner sends an exception when it isn't allowed to read one of the > files (or sub directory) during its scanning. Another RFE: http://forge.objectweb.org/tracker/index.php?func=detail&aid=304259&group_id=168&atid=350210 -Erik -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Free forum by Nabble | Edit this page |