You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by ch...@apache.org on 2003/07/18 02:17:23 UTC
cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
cheche 2003/07/17 17:17:23
Modified: src/resources/conf forrest.xmap
Added: src/resources/stylesheets text2document.xsl
Log:
Revision Changes Path
1.21 +11 -1 xml-forrest/src/resources/conf/forrest.xmap
Index: forrest.xmap
===================================================================
RCS file: /home/cvs/xml-forrest/src/resources/conf/forrest.xmap,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- forrest.xmap 5 Jul 2003 13:01:02 -0000 1.20
+++ forrest.xmap 18 Jul 2003 00:17:23 -0000 1.21
@@ -201,6 +201,16 @@
</map:match>
</map:when>
+ <map:when test="content/{1}.txt">
+ <map:match type="regexp" pattern="^(.*?)([^/]*).xml$">
+ <map:generate type="text2xml" src="content/{1}{2}.txt" />
+ <map:transform src="resources/stylesheets/text2document.xsl">
+ <map:parameter name="filename" value="{2}" />
+ </map:transform>
+ <map:serialize type="xml"/>
+ </map:match>
+ </map:when>
+
<map:otherwise>
<map:generate src="content/xdocs/{1}.xml" />
<map:call resource="transform-to-document">
1.1 xml-forrest/src/resources/stylesheets/text2document.xsl
Index: text2document.xsl
===================================================================
<?xml version="1.0"?>
<!--+
| Transforms TextGenerator output to document format.
|
| CVS $Id: text2document.xsl,v 1.1 2003/07/18 00:17:23 cheche Exp $
+-->
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output indent="yes"
method="xml"
doctype-public="-//APACHE//DTD Documentation V1.2//EN"
doctype-system="document-v12.dtd"
cdata-section-elements="source"/>
<xsl:param name="filename"/>
<xsl:template match="/">
<document>
<header>
<title>
<xsl:value-of select="$filename"/>
</title>
</header>
<body>
<source>
<xsl:value-of select="node()"/>
</source>
</body>
</document>
</xsl:template>
</xsl:stylesheet>
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
Thanks! I wasn't familiar with the TextGenerator. I'll test it tomorrow. But
is there a way to make it work with dos files? We use windows at our workstations.
Quoting Juan Jose Pablos <ch...@che-che.com>:
> Dave,
>
> I simplify a lot the code.
>
> The EOL charactre was due a problem on the format of your files (dos).
> There is not need to use chaperon format, you get a <text> </text> from
> the Cocoon TextGenerator.
>
> Please, would you mind text the changes so it works for you as well?
>
> Cheers
>
> Cheche
>
> cheche@apache.org wrote:
> > cheche 2003/07/17 17:17:23
> >
> > Modified: src/resources/conf forrest.xmap
> > Added: src/resources/stylesheets text2document.xsl
> > Log:
> >
> >
> > Revision Changes Path
> > 1.21 +11 -1 xml-forrest/src/resources/conf/forrest.xmap
> >
> > Index: forrest.xmap
> > ===================================================================
> > RCS file: /home/cvs/xml-forrest/src/resources/conf/forrest.xmap,v
> > retrieving revision 1.20
> > retrieving revision 1.21
> > diff -u -r1.20 -r1.21
> > --- forrest.xmap 5 Jul 2003 13:01:02 -0000 1.20
> > +++ forrest.xmap 18 Jul 2003 00:17:23 -0000 1.21
> > @@ -201,6 +201,16 @@
> > </map:match>
> > </map:when>
> >
> > + <map:when test="content/{1}.txt">
> > + <map:match type="regexp" pattern="^(.*?)([^/]*).xml$">
> > + <map:generate type="text2xml" src="content/{1}{2}.txt" />
> > + <map:transform src="resources/stylesheets/text2document.xsl">
> > + <map:parameter name="filename" value="{2}" />
> > + </map:transform>
> > + <map:serialize type="xml"/>
> > + </map:match>
> > + </map:when>
> > +
> > <map:otherwise>
> > <map:generate src="content/xdocs/{1}.xml" />
> > <map:call resource="transform-to-document">
> >
> >
> >
> > 1.1
> xml-forrest/src/resources/stylesheets/text2document.xsl
> >
> > Index: text2document.xsl
> > ===================================================================
> > <?xml version="1.0"?>
> >
> > <!--+
> > | Transforms TextGenerator output to document format.
> > |
> > | CVS $Id: text2document.xsl,v 1.1 2003/07/18 00:17:23 cheche Exp $
> > +-->
> >
> > <xsl:stylesheet version="1.0"
> > xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> >
> > <xsl:output indent="yes"
> > method="xml"
> > doctype-public="-//APACHE//DTD Documentation V1.2//EN"
> > doctype-system="document-v12.dtd"
> > cdata-section-elements="source"/>
> >
> > <xsl:param name="filename"/>
> >
> > <xsl:template match="/">
> > <document>
> > <header>
> > <title>
> > <xsl:value-of select="$filename"/>
> > </title>
> > </header>
> > <body>
> > <source>
> > <xsl:value-of select="node()"/>
> > </source>
> > </body>
> > </document>
> > </xsl:template>
> >
> > </xsl:stylesheet>
> >
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
>
> Not necessarily. The links *can* be there, or can oven not be there.
> For example, CSS styles can use images inside, but Cocoon does *not*
> crawl CSS files!
>
> Or if we want to include some html as-is, Cocoon will not crawl them,
> and the links that they have will not be copied.
I am not talking about that. I am talking about it a users wants to
display a file as text then it can just add this on a book.xml:
<readme label="README" href="README.txt" />
>
>
> There has already been a discussion on this, and you have partecipated.
> I regard that there was consensus, but if it's not the case please
> explain why WRT that discussion.
> I will post a summary in a next mail titled "[SUMMARY] Cleaning Forrest
> source directory madness".
>
I know that, AFAIK the only consensus was to leave for the next release
AND "fix properly" meaning, get rid of special purpose directories
altogether, and let the user partition things however they want.
>>> This would only be possible in a webapp, not a static generated
>>> website. Even
>>> then, most browsers can handle most formats. It is normally the end
>>> user who
>>> chooses if they want plain text (eg, to copy to a document), html
>>> (eg, to
>>> browse), pdf (eg, to print).
>>
>>
>> 1) I can not see the technical reason of why "This would only be
>> possible in a webapp". Please explain a bit futher.
>
>
> Content negotiation is dynamic. The CLI makes *one* request, not
> different ones.
>
The static content that we created would be added to an apache webserver
that provides the content negotiation.
I would like to create with forrest:
content.es.html
content.es.txt
content.en.html
content.en.txt
When added to an apache web server:
GET /content HTTP/1.1
should give me the right content based on my browser preferences.
>> 2) I do not talks just on formats, It could be diferent language.
>>
>> 3) Not all the user agents are end users. A search engine bot who
>> wants just the content in spanish.
>>
>> It is not me who has these clever ideas (I wish!) , it is on the
>> protocol stuff: http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
>
>
> Do you know Cocoon? Look at it, there are all the things you need.
> But remember that static versions of the site will always be less
> dynamic, of course.
>
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote, On 21/07/2003 20.46:
> Dave,
>
>>>
>>> As far as I am aware you only crawled files that are include on the
>>> book.xml / site.xml files.
>>
>> All links on a page are crawled, unless specified in filterlinks.xsl.
>
> The way the links got on a page is defined either on site.xml or a local
> book.xml file.
Not necessarily. The links *can* be there, or can oven not be there.
For example, CSS styles can use images inside, but Cocoon does *not*
crawl CSS files!
Or if we want to include some html as-is, Cocoon will not crawl them,
and the links that they have will not be copied.
>> I have seen a lot of different ideas and suggestions about Forrest's
>> directories
>> over just the few weeks I've been on the list. I suggest we get a
>> wiki set up,
>> post all the different ideas and allow for comments. After some time and
>> perhaps IRC meetings, we could establish a firm vision of what the
>> directories
>> will look like in 0.5, 0.6, 1.0 or whatever.
>>
>
> If there is a lot of ideas on this is because not many people like that
> set up.
...
> I do not think we are going to have any change on this release, but
> having a direction to follow would helps.
There has already been a discussion on this, and you have partecipated.
I regard that there was consensus, but if it's not the case please
explain why WRT that discussion.
I will post a summary in a next mail titled "[SUMMARY] Cleaning Forrest
source directory madness".
>> This would only be possible in a webapp, not a static generated
>> website. Even
>> then, most browsers can handle most formats. It is normally the end
>> user who
>> chooses if they want plain text (eg, to copy to a document), html (eg, to
>> browse), pdf (eg, to print).
>
> 1) I can not see the technical reason of why "This would only be
> possible in a webapp". Please explain a bit futher.
Content negotiation is dynamic. The CLI makes *one* request, not
different ones.
> 2) I do not talks just on formats, It could be diferent language.
>
> 3) Not all the user agents are end users. A search engine bot who wants
> just the content in spanish.
>
> It is not me who has these clever ideas (I wish!) , it is on the
> protocol stuff: http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
Do you know Cocoon? Look at it, there are all the things you need.
But remember that static versions of the site will always be less
dynamic, of course.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Juan Jose Pablos <ch...@che-che.com>:
> Dave,
>
> >>
> >>As far as I am aware you only crawled files that are include on the
> >>book.xml / site.xml files.
> >
> >
> > All links on a page are crawled, unless specified in filterlinks.xsl.
> >
>
> The way the links got on a page is defined either on site.xml or a local
> book.xml file.
>
Or from a <link> in the content.
> > This would only be possible in a webapp, not a static generated website.
> Even
> > then, most browsers can handle most formats. It is normally the end user
> who
> > chooses if they want plain text (eg, to copy to a document), html (eg, to
> > browse), pdf (eg, to print).
> >
> >
>
> 1) I can not see the technical reason of why "This would only be
> possible in a webapp". Please explain a bit futher.
>
You are right. I didn't think the whole thing through.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave,
>>
>>As far as I am aware you only crawled files that are include on the
>>book.xml / site.xml files.
>
>
> All links on a page are crawled, unless specified in filterlinks.xsl.
>
The way the links got on a page is defined either on site.xml or a local
book.xml file.
>
> I have seen a lot of different ideas and suggestions about Forrest's directories
> over just the few weeks I've been on the list. I suggest we get a wiki set up,
> post all the different ideas and allow for comments. After some time and
> perhaps IRC meetings, we could establish a firm vision of what the directories
> will look like in 0.5, 0.6, 1.0 or whatever.
>
If there is a lot of ideas on this is because not many people like that
set up.
Have you realize that no one talks about the use of "ant"?
I am not sure if the problem reside on the format we use to comunicate.
But feel free to create a wiki to define this.
I do not think we are going to have any change on this release, but
having a direction to follow would helps.
>
> This would only be possible in a webapp, not a static generated website. Even
> then, most browsers can handle most formats. It is normally the end user who
> chooses if they want plain text (eg, to copy to a document), html (eg, to
> browse), pdf (eg, to print).
>
>
1) I can not see the technical reason of why "This would only be
possible in a webapp". Please explain a bit futher.
2) I do not talks just on formats, It could be diferent language.
3) Not all the user agents are end users. A search engine bot who wants
just the content in spanish.
It is not me who has these clever ideas (I wish!) , it is on the
protocol stuff: http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
Cheers
Cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Juan Jose Pablos <ch...@che-che.com>:
> Nicola,
>
> > At first, I thought that having one only directory for content was ok.
> > But then users would want to have both html files that are shown as-is,
> > and html files that are decorated like other xml files.
>
> On the text example, you can have the content as-is, and the content
> decorated. You need to call the right extension.
>
> > Another problem comes with the fact that we may want to all files that
> > are not able to be crawled by Cocoon.
>
> As far as I am aware you only crawled files that are include on the
> book.xml / site.xml files.
All links on a page are crawled, unless specified in filterlinks.xsl.
> >
> > 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).
> >
>
> Could you give more info on what exactly did not work?
I have seen a lot of different ideas and suggestions about Forrest's directories
over just the few weeks I've been on the list. I suggest we get a wiki set up,
post all the different ideas and allow for comments. After some time and
perhaps IRC meetings, we could establish a firm vision of what the directories
will look like in 0.5, 0.6, 1.0 or whatever.
>
> I would like to see at least this to be include on the wish list.
>
> how difficult is to get here?
>
> http://httpd.apache.org/docs/content-negotiation.html
>
This would only be possible in a webapp, not a static generated website. Even
then, most browsers can handle most formats. It is normally the end user who
chooses if they want plain text (eg, to copy to a document), html (eg, to
browse), pdf (eg, to print).
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
> At first, I thought that having one only directory for content was ok.
> But then users would want to have both html files that are shown as-is,
> and html files that are decorated like other xml files.
On the text example, you can have the content as-is, and the content
decorated. You need to call the right extension.
> Another problem comes with the fact that we may want to all files that
> are not able to be crawled by Cocoon.
As far as I am aware you only crawled files that are include on the
book.xml / site.xml files.
Is it possible to have this:
<readme label="README" href="README.txt" />
>
> 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).
>
Could you give more info on what exactly did not work?
I would like to see at least this to be include on the wish list.
how difficult is to get here?
http://httpd.apache.org/docs/content-negotiation.html
Cheers,
Cheche
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)
---------------------------------------------------------------------
Directory structure in 0.6 (Re: cvs commit: ...)
Posted by Jeff Turner <je...@apache.org>.
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: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote, On 21/07/2003 15.24:
> Quoting Juan Jose Pablos <ch...@che-che.com>:
...
>>I rather prefer to have only *one* DOCUMENT_ROOT and stop having to
>>maintain two directories trees. any thoughts?
>
> This makes sense to me. The pipelines already distinguish based on extension, I
> don't see a reason to have the 'xdocs' directory ... it just makes things more
> complicated and difficult for users to maintain.
There was a discussion recently on this...
At first, I thought that having one only directory for content was ok.
But then users would want to have both html files that are shown as-is,
and html files that are decorated like other xml files.
Another problem comes with the fact that we may want to all files that
are not able to be crawled by Cocoon.
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?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Juan Jose Pablos <ch...@che-che.com>:
> Dave,
>
> > It would be nice to have all 3 formats available. Can this also be done
> from
> > the xdocs directory?
> >
> > It is my understanding that only files in xdocs/ are modified and that all
> other
> > files in content/ are kept as they are. For example, .cwiki files are not
> XML
> > but they are in the xdocs/ directory. Since .cwiki and .txt files can be
> > transformed to the Document XML format, I think it makes sense to have them
> in
> > the xdocs/ directory.
> >
>
> If your understanding that only files in xdocs/ are modified why should
> I put a rule to allow txt to be kept as they are?
>
>
> I rather prefer to have only *one* DOCUMENT_ROOT and stop having to
> maintain two directories trees. any thoughts?
>
This makes sense to me. The pipelines already distinguish based on extension, I
don't see a reason to have the 'xdocs' directory ... it just makes things more
complicated and difficult for users to maintain.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave,
> It would be nice to have all 3 formats available. Can this also be done from
> the xdocs directory?
>
> It is my understanding that only files in xdocs/ are modified and that all other
> files in content/ are kept as they are. For example, .cwiki files are not XML
> but they are in the xdocs/ directory. Since .cwiki and .txt files can be
> transformed to the Document XML format, I think it makes sense to have them in
> the xdocs/ directory.
>
If your understanding that only files in xdocs/ are modified why should
I put a rule to allow txt to be kept as they are?
There is two rules for the txt content:
one in forrest map:
<map:match pattern="**.xml">
<map:select type="exists">
<map:when test="content/{1}.txt">
<map:match type="regexp" pattern="^(.*?)([^/]*).xml$">
<map:generate type="text2xml" src="content/{1}{2}.txt" />
another one in raw.xmap:
<map:match pattern="**.txt">
<map:read src="content/{0}" mime-type="text/plain" />
</map:match>
So if I want to allow an agent to receive xml,html and txt, I have to
use the content/ or content/xdocs in forrest.xmap and in raw.map.
I rather prefer to have only *one* DOCUMENT_ROOT and stop having to
maintain two directories trees. any thoughts?
Cheers
Cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Juan Jose Pablos <ch...@che-che.com>:
> Dave,
>
> > <map:generate type="text2xml" src="content/{1}{2}.txt" />
> > should be
> > <map:generate type="text2xml" src="content/xdocs/{1}{2}.txt" />
>
>
> Well, I am not sure about this. If you put a README.txt on the content/
> directory then you can call:
>
> README.html --> full look and feel
> README.xml --> xml format
> README.txt --> plain text
>
> I am not sure about other formats but this way looks for me the right one.
>
> Thought anyone?
>
> Cheers,
> Cheche
>
It would be nice to have all 3 formats available. Can this also be done from
the xdocs directory?
It is my understanding that only files in xdocs/ are modified and that all other
files in content/ are kept as they are. For example, .cwiki files are not XML
but they are in the xdocs/ directory. Since .cwiki and .txt files can be
transformed to the Document XML format, I think it makes sense to have them in
the xdocs/ directory.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave,
> <map:generate type="text2xml" src="content/{1}{2}.txt" />
> should be
> <map:generate type="text2xml" src="content/xdocs/{1}{2}.txt" />
Well, I am not sure about this. If you put a README.txt on the content/
directory then you can call:
README.html --> full look and feel
README.xml --> xml format
README.txt --> plain text
I am not sure about other formats but this way looks for me the right one.
Thought anyone?
Cheers,
Cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Juan Jose Pablos <ch...@che-che.com>:
> Stephan,
>
> >>
> >>I fixed this on the style sheet. It removes the character, but I
> >>guess that this is valid only for windows machines and it could be
> >>diferent on other platforms.
> >
> >
> > Perhaps it is better if I change the implemetation of the TextGenerator?!
> > I replaced the line endings because I had troubles if I got
> > text files from different platforms(win/unix/mac). By replacing them
> > I have always the correct line ending for the current platform.
> >
> > But I can make this optional, if you want.
> >
> > Stephan.
>
> I am not sure how to resolve this.
>
> I guess that adding a flag should be enough:
>
> <map:generator name="text2xml"
> src="org.apache.cocoon.generation.TextGenerator" >
> <parameter name="replace-line-ending" value="false"/>
> <map:generator/>
>
> After that Dave should test to see if that works for him.
>
> Cheers,
> Cheche
>
>
The stylesheet change works for me. The parameter to TextGenerator seems like a
better idea to me.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Stephan,
>>
>>I fixed this on the style sheet. It removes the character, but I
>>guess that this is valid only for windows machines and it could be
>>diferent on other platforms.
>
>
> Perhaps it is better if I change the implemetation of the TextGenerator?!
> I replaced the line endings because I had troubles if I got
> text files from different platforms(win/unix/mac). By replacing them
> I have always the correct line ending for the current platform.
>
> But I can make this optional, if you want.
>
> Stephan.
I am not sure how to resolve this.
I guess that adding a flag should be enough:
<map:generator name="text2xml"
src="org.apache.cocoon.generation.TextGenerator" >
<parameter name="replace-line-ending" value="false"/>
<map:generator/>
After that Dave should test to see if that works for him.
Cheers,
Cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Stephan Michels <st...@apache.org>.
On Tue, 22 Jul 2003, Juan Jose Pablos wrote:
> Dave,Stephan,
>
> Dave Brondsema wrote:
> > Quoting Stephan Michels <st...@apache.org>:
> >>On Fri, 18 Jul 2003, Dave Brondsema wrote:
> >>
> >>This is intentional, the TextGenerator replace every line ending
> >>by System.getProperty("line.separator").
> >>
> >>Cause this troubles?!
> >>
> >>Stephan.
> >>
>
> I fixed this on the style sheet. It removes the character, but I
> guess that this is valid only for windows machines and it could be
> diferent on other platforms.
Perhaps it is better if I change the implemetation of the TextGenerator?!
I replaced the line endings because I had troubles if I got
text files from different platforms(win/unix/mac). By replacing them
I have always the correct line ending for the current platform.
But I can make this optional, if you want.
Stephan.
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave,Stephan,
Dave Brondsema wrote:
> Quoting Stephan Michels <st...@apache.org>:
>>On Fri, 18 Jul 2003, Dave Brondsema wrote:
>>
>>This is intentional, the TextGenerator replace every line ending
>>by System.getProperty("line.separator").
>>
>>Cause this troubles?!
>>
>>Stephan.
>>
I fixed this on the style sheet. It removes the character, but I
guess that this is valid only for windows machines and it could be
diferent on other platforms.
Cheers,
Cheche
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Stephan Michels <st...@apache.org>:
> On Fri, 18 Jul 2003, Dave Brondsema wrote:
>
> > <map:generate type="text2xml" src="content/{1}{2}.txt" />
> > should be
> > <map:generate type="text2xml" src="content/xdocs/{1}{2}.txt" />
> >
> >
> > Also, I changed my text file line endings to unix format, but it still
> puts
> > at the end of each line. I am running forrest on windows.
>
> This is intentional, the TextGenerator replace every line ending
> by System.getProperty("line.separator").
>
> Cause this troubles?!
>
> Stephan.
>
The HTML that is generated is like this:
[javadoc] Constructing Javadoc information...
[javadoc] Building tree for all the packages and classes...
[javadoc] Building index for all the packages and classes...
I think it's okay for TextGenerator to do the line ending replacement, but
somewhere in the pipeline the CR turns into and that needs to be fixed.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Stephan,
I am using linux, so I am not able to see the error, I can fix that on
the stylesheet, but I would like to know if I am getting the right input
from the TextGenerator.
Stephan Michels wrote:
>
> On Fri, 18 Jul 2003, Dave Brondsema wrote:
>>
>>Also, I changed my text file line endings to unix format, but it still puts
>> at the end of each line. I am running forrest on windows.
>
>
> This is intentional, the TextGenerator replace every line ending
> by System.getProperty("line.separator").
>
> Cause this troubles?!
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Stephan Michels <st...@apache.org>.
On Fri, 18 Jul 2003, Dave Brondsema wrote:
> <map:generate type="text2xml" src="content/{1}{2}.txt" />
> should be
> <map:generate type="text2xml" src="content/xdocs/{1}{2}.txt" />
>
>
> Also, I changed my text file line endings to unix format, but it still puts
> at the end of each line. I am running forrest on windows.
This is intentional, the TextGenerator replace every line ending
by System.getProperty("line.separator").
Cause this troubles?!
Stephan.
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Dave Brondsema <da...@brondsema.net>.
<map:generate type="text2xml" src="content/{1}{2}.txt" />
should be
<map:generate type="text2xml" src="content/xdocs/{1}{2}.txt" />
Also, I changed my text file line endings to unix format, but it still puts
at the end of each line. I am running forrest on windows.
Thanks Cheche!
Quoting Juan Jose Pablos <ch...@che-che.com>:
> Dave,
>
> I simplify a lot the code.
>
> The EOL charactre was due a problem on the format of your files (dos).
> There is not need to use chaperon format, you get a <text> </text> from
> the Cocoon TextGenerator.
>
> Please, would you mind text the changes so it works for you as well?
>
> Cheers
>
> Cheche
>
> cheche@apache.org wrote:
> > cheche 2003/07/17 17:17:23
> >
> > Modified: src/resources/conf forrest.xmap
> > Added: src/resources/stylesheets text2document.xsl
> > Log:
> >
> >
> > Revision Changes Path
> > 1.21 +11 -1 xml-forrest/src/resources/conf/forrest.xmap
> >
> > Index: forrest.xmap
> > ===================================================================
> > RCS file: /home/cvs/xml-forrest/src/resources/conf/forrest.xmap,v
> > retrieving revision 1.20
> > retrieving revision 1.21
> > diff -u -r1.20 -r1.21
> > --- forrest.xmap 5 Jul 2003 13:01:02 -0000 1.20
> > +++ forrest.xmap 18 Jul 2003 00:17:23 -0000 1.21
> > @@ -201,6 +201,16 @@
> > </map:match>
> > </map:when>
> >
> > + <map:when test="content/{1}.txt">
> > + <map:match type="regexp" pattern="^(.*?)([^/]*).xml$">
> > + <map:generate type="text2xml" src="content/{1}{2}.txt" />
> > + <map:transform src="resources/stylesheets/text2document.xsl">
> > + <map:parameter name="filename" value="{2}" />
> > + </map:transform>
> > + <map:serialize type="xml"/>
> > + </map:match>
> > + </map:when>
> > +
> > <map:otherwise>
> > <map:generate src="content/xdocs/{1}.xml" />
> > <map:call resource="transform-to-document">
> >
> >
> >
> > 1.1
> xml-forrest/src/resources/stylesheets/text2document.xsl
> >
> > Index: text2document.xsl
> > ===================================================================
> > <?xml version="1.0"?>
> >
> > <!--+
> > | Transforms TextGenerator output to document format.
> > |
> > | CVS $Id: text2document.xsl,v 1.1 2003/07/18 00:17:23 cheche Exp $
> > +-->
> >
> > <xsl:stylesheet version="1.0"
> > xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> >
> > <xsl:output indent="yes"
> > method="xml"
> > doctype-public="-//APACHE//DTD Documentation V1.2//EN"
> > doctype-system="document-v12.dtd"
> > cdata-section-elements="source"/>
> >
> > <xsl:param name="filename"/>
> >
> > <xsl:template match="/">
> > <document>
> > <header>
> > <title>
> > <xsl:value-of select="$filename"/>
> > </title>
> > </header>
> > <body>
> > <source>
> > <xsl:value-of select="node()"/>
> > </source>
> > </body>
> > </document>
> > </xsl:template>
> >
> > </xsl:stylesheet>
> >
Re: cvs commit: xml-forrest/src/resources/stylesheets text2document.xsl
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave,
I simplify a lot the code.
The EOL charactre was due a problem on the format of your files (dos).
There is not need to use chaperon format, you get a <text> </text> from
the Cocoon TextGenerator.
Please, would you mind text the changes so it works for you as well?
Cheers
Cheche
cheche@apache.org wrote:
> cheche 2003/07/17 17:17:23
>
> Modified: src/resources/conf forrest.xmap
> Added: src/resources/stylesheets text2document.xsl
> Log:
>
>
> Revision Changes Path
> 1.21 +11 -1 xml-forrest/src/resources/conf/forrest.xmap
>
> Index: forrest.xmap
> ===================================================================
> RCS file: /home/cvs/xml-forrest/src/resources/conf/forrest.xmap,v
> retrieving revision 1.20
> retrieving revision 1.21
> diff -u -r1.20 -r1.21
> --- forrest.xmap 5 Jul 2003 13:01:02 -0000 1.20
> +++ forrest.xmap 18 Jul 2003 00:17:23 -0000 1.21
> @@ -201,6 +201,16 @@
> </map:match>
> </map:when>
>
> + <map:when test="content/{1}.txt">
> + <map:match type="regexp" pattern="^(.*?)([^/]*).xml$">
> + <map:generate type="text2xml" src="content/{1}{2}.txt" />
> + <map:transform src="resources/stylesheets/text2document.xsl">
> + <map:parameter name="filename" value="{2}" />
> + </map:transform>
> + <map:serialize type="xml"/>
> + </map:match>
> + </map:when>
> +
> <map:otherwise>
> <map:generate src="content/xdocs/{1}.xml" />
> <map:call resource="transform-to-document">
>
>
>
> 1.1 xml-forrest/src/resources/stylesheets/text2document.xsl
>
> Index: text2document.xsl
> ===================================================================
> <?xml version="1.0"?>
>
> <!--+
> | Transforms TextGenerator output to document format.
> |
> | CVS $Id: text2document.xsl,v 1.1 2003/07/18 00:17:23 cheche Exp $
> +-->
>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>
> <xsl:output indent="yes"
> method="xml"
> doctype-public="-//APACHE//DTD Documentation V1.2//EN"
> doctype-system="document-v12.dtd"
> cdata-section-elements="source"/>
>
> <xsl:param name="filename"/>
>
> <xsl:template match="/">
> <document>
> <header>
> <title>
> <xsl:value-of select="$filename"/>
> </title>
> </header>
> <body>
> <source>
> <xsl:value-of select="node()"/>
> </source>
> </body>
> </document>
> </xsl:template>
>
> </xsl:stylesheet>
>
>
>