You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2003/07/22 12:17:33 UTC
Directory structure in 0.6 (Re: cvs commit: ...)
On Mon, Jul 21, 2003 at 04:12:21PM +0200, Nicola Ken Barozzi wrote:
...
> So we came to the simple solution to have two trees: one for the stuff
> that Cocoon *can* process, and another one for the things that Cocoon
> must *not* process.
>
> ATM the content/xdocs nesting is in fact confusing, but we plan to
> change that in the next release (BTW, it came out of a tentative to
> merge into one the trees, but believe me, it doesn't work, I used it on
> some projects and had to revert).
>
> Something like
>
> /content/**
> /raw/**
>
> Jeff, do you remember the dir names and the other decisions we took
> about the resources/images dirs?
IIRC,
src/documentation/content/
src/documentation/content/raw/
Then within these directories, users can do whatever they want, although
the default sitemap would support commonly used things like
src/documentation/content/images/
Though, the necessity of raw/ is rather annoying, as we still have two
separate content trees with an identical structure. If index.xml refers
to a pregenerated sales.pdf, we'd have:
src/documentation/content/index.xml
src/documentation/content/raw/sales.pdf
Perhaps we could rather use marker attributes in site.xml to indicate raw
content:
<site>
...
<salesreport href="sales.pdf" binary="true"/>
...
</site>
And then just have:
src/documentation/content/index.xml
src/documentation/content/sales.pdf
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: Directory structure in 0.6 (Re: cvs commit: ...)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
> And if the resource exists but I still want to transform it?
> And if I don't want to crawl all the source files?
> And if I *cannot* crawl them?
>
> Listen, this has come up a lot of times, and *was* in the Cocoon
> pipeline, if not already there, and I proposed this several months ago.
> Not only it seems that you are not looking in the archives, but that you
> are also not reading my mails with references I have dug up for you.
I am trying to find the best way than forrest can make out of a
HTTP_REQUEST, I took that line from forrest.xmap, and I think that it is
a good choice to have it.
I have not got any case where I do a pdf-pdf or png-png tranformation, I
am not sure if many people use forrest for that (where is the code anyway?)
I am happy with any solution that keep things clean, like having only
one content directory.
If you have source docs that you do not want to be touch/can not by
forrest, why do you put it in the first place?
If it is only because you need a reference on the menu (ie <javadocs
href="api/">) Maybe we need to create just an element similar to virtual
directory.
> "
> Mind me, we still add a **.* matcher at the end of the
> content-handling pipeline, so that content/** can still contain anything
> (ie cocoon can process it but in this case can also decide to just pass
> along).
>
> But as you know in this way I cannot easily cater for the special case
> in which I want to explicitly have something as-is...
> "
>
> Your proposal does not work in case you cannot use the extension to
> decide if giving the resource raw or not, and in the case in which these
> sources are non-traversable.
>
Fine then.
Cheers,
Cheche
Re: Directory structure in 0.6 (Re: cvs commit: ...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote, On 22/07/2003 12.42:
...
>
> What about?
>
> <map:select type="exists">
> <map:when test="cocoon:/{1}@href">
> ...
>
>
> Basicaly if a resource exist then give the resource as-is, if the
> resource does not exist try to transform it from something else.
And if the resource exists but I still want to transform it?
And if I don't want to crawl all the source files?
And if I *cannot* crawl them?
Listen, this has come up a lot of times, and *was* in the Cocoon
pipeline, if not already there, and I proposed this several months ago.
Not only it seems that you are not looking in the archives, but that you
are also not reading my mails with references I have dug up for you.
"
Mind me, we still add a **.* matcher at the end of the
content-handling pipeline, so that content/** can still contain anything
(ie cocoon can process it but in this case can also decide to just pass
along).
But as you know in this way I cannot easily cater for the special case
in which I want to explicitly have something as-is...
"
Your proposal does not work in case you cannot use the extension to
decide if giving the resource raw or not, and in the case in which these
sources are non-traversable.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Directory structure in 0.6 (Re: cvs commit: ...)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
> Though, the necessity of raw/ is rather annoying, as we still have two
> separate content trees with an identical structure. If index.xml refers
> to a pregenerated sales.pdf, we'd have:
>
> src/documentation/content/index.xml
> src/documentation/content/raw/sales.pdf
>
> Perhaps we could rather use marker attributes in site.xml to indicate raw
> content:
>
> <site>
> ...
> <salesreport href="sales.pdf" binary="true"/>
> ...
> </site>
>
What about?
<map:select type="exists">
<map:when test="cocoon:/{1}@href">
...
Basicaly if a resource exist then give the resource as-is, if the
resource does not exist try to transform it from something else.
Cheers,
Cheche
Re: Directory structure in 0.6 (Re: cvs commit: ...)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Jul 23, 2003 at 08:23:08AM +0200, Nicola Ken Barozzi wrote:
>
> NOTE: I did not see this come out on gmane, which is the system I use to
> read this ML. I hope I'm not loosing other mails...
No, the mail to forrest-dev@ bounced because I was sending with an
unusual From header. In case you're wondering why you always get a
separate email, it's because your mailer sets a Reply-To:
nicolaken@apache.org header ;P
--Jeff
>
> Jeff Turner wrote, On 23/07/2003 2.56:
> ...
> >Well we can make binary=true an inheritable attribute then:
> >
> > <apidocs binary="true">
> > ...
> > </apidocs>
> >
> ...
> >If we have an inheritable @binary, then having a special raw/ directory
> >is equivalent to hardcoding:
> >
> > <raw href="raw/" binary="true">
> > ...
> > </raw>
>
> Ok, I buy it :-)
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: Directory structure in 0.6 (Re: cvs commit: ...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
NOTE: I did not see this come out on gmane, which is the system I use to
read this ML. I hope I'm not loosing other mails...
Jeff Turner wrote, On 23/07/2003 2.56:
...
> Well we can make binary=true an inheritable attribute then:
>
> <apidocs binary="true">
> ...
> </apidocs>
>
...
> If we have an inheritable @binary, then having a special raw/ directory
> is equivalent to hardcoding:
>
> <raw href="raw/" binary="true">
> ...
> </raw>
Ok, I buy it :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Directory structure in 0.6 (Re: cvs commit: ...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 22/07/2003 12.17:
...
> Though, the necessity of raw/ is rather annoying, as we still have two
> separate content trees with an identical structure. If index.xml refers
> to a pregenerated sales.pdf, we'd have:
>
> src/documentation/content/index.xml
> src/documentation/content/raw/sales.pdf
>
> Perhaps we could rather use marker attributes in site.xml to indicate raw
> content:
>
> <site>
> ...
> <salesreport href="sales.pdf" binary="true"/>
> ...
> </site>
>
> And then just have:
>
> src/documentation/content/index.xml
> src/documentation/content/sales.pdf
The issue here was when users wanted to add a large number of raw docs,
like javadocs for example.
Now, we could also say that in that case we should be able to "mount"
other directories as raw or as content, so I could be ok with your
solution.
I mean, it seems it could be ok, and given my use of the raw dir it is,
but would it be so also for other users?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------