You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 2002/11/04 11:02:32 UTC
'broken link' causes..
this 'broken link' stuff is really starting to frost my pumpkin..
what the flying moose ears are the possible causes, and how can i get
forrest to tell me in more detail which one applies? so far it seems
to varf with one on *any* non-.xml file i try to include, such as .pdf
or verbatim .html.
Re: 'broken link' causes..
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Mon, Nov 04, 2002 at 05:30:32PM +0100, Nicola Ken Barozzi wrote:
>
>>Rodent of Unusual Size wrote:
>>
>>>Jeff Turner wrote:
>>>
>>>
>>>>Continuing on from this..
>>>>
>>>>The solution is to add a custom sitemap rule for "forms/*.pdf",
>>>>and put it before the more general "**.pdf" rule ('**' matches
>>>>subdirectories).
>>>
>>>
>>>ew.
>>>
>>>
>>>
>>>>So, to fix incubator-site:
>>>
>>>
>>>in other words, any xml-unaware person wanting to do something like
>>>this will need to wave a dead chicken over the sitemap, typing
>>>in tongues they don't understand. i can accept this for now, but
>>>i surely hope this is only a we're-still-in-alpha workaround and
>>>not considered an final solution..
>>
>>Yup, it's a workaround.
>
>
> I wouldn't say that.. it's _the solution_. Anything we add on top of
> this is just making _the solution_ easier for users to apply.
>
> "The goal of the sitemap is to allow non-programmers to create web sites
> and web applications built from logic components and XML documents."
> http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html
>
> Note "non-programmers" there.
>
> The idea of controlling the whole website's output from one file is what
> makes Forrest (potentially) not suck :) Rather than hide it, I think we
> should a) simplify it drastically, b) make it central to the Forrest
> Indoctrination Program.
>
> Just MHO :)
I agree, it's just that the simple requirement of just copying resources
as-is should not need to edit the sitemap, it should be a pre-made rule.
For the rest, I can only agree, adding that a simplified editor for the
sitemap would really rock!
Just MHO ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: 'broken link' causes..
Posted by Jeff Turner <je...@apache.org>.
On Mon, Nov 04, 2002 at 05:30:32PM +0100, Nicola Ken Barozzi wrote:
>
> Rodent of Unusual Size wrote:
> >Jeff Turner wrote:
> >
> >>Continuing on from this..
> >>
> >>The solution is to add a custom sitemap rule for "forms/*.pdf",
> >>and put it before the more general "**.pdf" rule ('**' matches
> >>subdirectories).
> >
> >
> >ew.
> >
> >
> >>So, to fix incubator-site:
> >
> >
> >in other words, any xml-unaware person wanting to do something like
> >this will need to wave a dead chicken over the sitemap, typing
> >in tongues they don't understand. i can accept this for now, but
> >i surely hope this is only a we're-still-in-alpha workaround and
> >not considered an final solution..
>
> Yup, it's a workaround.
I wouldn't say that.. it's _the solution_. Anything we add on top of
this is just making _the solution_ easier for users to apply.
"The goal of the sitemap is to allow non-programmers to create web sites
and web applications built from logic components and XML documents."
http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html
Note "non-programmers" there.
The idea of controlling the whole website's output from one file is what
makes Forrest (potentially) not suck :) Rather than hide it, I think we
should a) simplify it drastically, b) make it central to the Forrest
Indoctrination Program.
Just MHO :)
--Jeff
Re: 'broken link' causes..
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Rodent of Unusual Size wrote:
> Jeff Turner wrote:
>
>>Continuing on from this..
>>
>>The solution is to add a custom sitemap rule for "forms/*.pdf",
>>and put it before the more general "**.pdf" rule ('**' matches
>>subdirectories).
>
>
> ew.
>
>
>>So, to fix incubator-site:
>
>
> in other words, any xml-unaware person wanting to do something like
> this will need to wave a dead chicken over the sitemap, typing
> in tongues they don't understand. i can accept this for now, but
> i surely hope this is only a we're-still-in-alpha workaround and
> not considered an final solution..
Yup, it's a workaround.
The final solutions are always to have the user confortable and make
things go smooth, don't worry.
Sometimes you will here about why we have done something before, but
that's not necessarily what we will do from now on.. actually, the
opposite :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: 'broken link' causes..
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Jeff Turner wrote:
>
> Continuing on from this..
>
> The solution is to add a custom sitemap rule for "forms/*.pdf",
> and put it before the more general "**.pdf" rule ('**' matches
> subdirectories).
ew.
> So, to fix incubator-site:
in other words, any xml-unaware person wanting to do something like
this will need to wave a dead chicken over the sitemap, typing
in tongues they don't understand. i can accept this for now, but
i surely hope this is only a we're-still-in-alpha workaround and
not considered an final solution..
Re: 'broken link' causes..
Posted by Steven Noels <st...@outerthought.org>.
Jeff Turner wrote:
> While I'm clarifying.. what's the difference between a 'resource' and
> 'content'? I'm not too sure.. I think 'resources' are things like XSLT
> stylesheets. Not something served up to the user, whereas 'content' is.
> By that rule, images should be in content/, not resources/.
>
> What do people think about changing that?
you're right - go for it
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
RE: [RT] Site versioning, staging and deployment ( was Re: documentation/content made available to sitemap (Re: 'broken link' causes..))
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Tuesday, November 05, 2002 2:13 AM
>
> These are the requirements I think I have understood:
>
> 1) the system must be updateable to the live site manually
> 2) an automatic system may be used to generate a dev
> version of the site
> 4) the source must be committed to a VCS
> 5) the results of the docs build must be committed to a VCS,
> to keep history of the generated version
> 6) an automatic system may publish the site from VCS with a
> sensible time delay, possibly random to minimize the
> possibility of bad content being pushed intentionally
> or erroneously on the site
content, pages and folders could have some status property to indicate their
current state (editorial, archive, static, etc). This could or could not be
observed by the build system to only build what is appropriate for the stage of
the project.
> 7) the automatic publishing system must run from the
> destination site for security reasons: it will
> _pull_ content from the generation site.
I would think that you *should* copy to the live site. The site should be
developed, tested, certified, then copied to 'live.'
When it is certified, it is like a gold master from CDROM days
Staging is nothing new - I did not come up this methodology - it is tried and
tested. I think it also shows your client/whoever-you-serve that you are taking
a professional approach to the project's development. It simplifies things a
great deal. You always are sure that only a certified site will be pushed live.
best,
-Rob
> 8) The document build system should not reside in VCS;
> it's recommended that in VCS there is an automated
> system to aid in the installation of the build system.
>
>
> I don't agree with all, but nevertheless we must address them, and come
> to a solution to all the _needs_ that bring users to define these
> requirements.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
[RT] Site versioning, staging and deployment ( was Re: documentation/content
made available to sitemap (Re: 'broken link' causes..))
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Robert Koberg wrote:
> Hi,
>
> <rambling>
> What about using subversion as the repos? You can set properties +
> on a 'thing'.
> Then some bright cocoon or forrest developer can come up with a way
> to merge these properties into some kind of mapping XML to be used
> in the transformation.
>
> In fact the subversion repos could serve the appropriate version
> of the site (to all stagiing environments).
>
> You can also get conflicts back as well-formed XML so sometimes,
> you might be able to fix a merge or provide a gui for
> non-technical users to fix it.
> </rambling>
I think that it's in the best interest of the users to have an all-java
solution in Forrest, and be able to use the filesystem as now, so I
won't want to tie Forrest to subversion.
Besides, Jakarta Slide is a CMS in Java that can use WebDav and
eventually use Subversion as a backend too.
That said, the fact you brought up subversion gives me the opportunity
to start a discussion about how to manage real-life Forrest sites.
With Mr. Rodent, we have talked about what his expectations were with
Forrest usage, and I summed them up in my head with all the other stuff
heard on the dozen lists I have polled.
These are the requirements I think I have understood:
1) the system must be updateable to the live site manually
2) an automatic system may be used to generate a dev
version of the site
4) the source must be committed to a VCS
5) the results of the docs build must be committed to a VCS,
to keep history of the generated version
6) an automatic system may publish the site from VCS with a
sensible time delay, possibly random to minimize the
possibility of bad content being pushed intentionally
or erroneously on the site
7) the automatic publishing system must run from the
destination site for security reasons: it will
_pull_ content from the generation site.
8) The document build system should not reside in VCS;
it's recommended that in VCS there is an automated
system to aid in the installation of the build system.
I don't agree with all, but nevertheless we must address them, and come
to a solution to all the _needs_ that bring users to define these
requirements.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: documentation/content made available to sitemap (Re: 'broken link' causes..)
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
<rambling>
What about using subversion as the repos? You can set properties on a 'thing'.
Then some bright cocoon or forrest developer can come up with a way to merge
these properties into some kind of mapping XML to be used in the transformation.
In fact the subversion repos could serve the appropriate version of the site (to
all stagiing environments).
You can also get conflicts back as well-formed XML so sometimes, you might be
able to fix a merge or provide a gui for non-technical users to fix it.
</rambling>
best,
-Rob
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Monday, November 04, 2002 8:37 AM
> To: forrest-dev@xml.apache.org
> Subject: Re: documentation/content made available to sitemap (Re:
> 'broken link' causes..)
>
>
>
> Jeff Turner wrote:
> > On Mon, Nov 04, 2002 at 05:01:35PM +0100, Nicola Ken Barozzi wrote:
> >
> >>Jeff Turner wrote:
> >>[...]
> >>
> >>>While I'm clarifying.. what's the difference between a 'resource' and
> >>>'content'? I'm not too sure.. I think 'resources' are things like XSLT
> >>>stylesheets. Not something served up to the user, whereas 'content' is.
> >>>By that rule, images should be in content/, not resources/.
> >>>
> >>>What do people think about changing that?
> >>
> >>Put the sources in ./documentation/**
> >>
> >>So we have
> >>
> >> ./documentation/index.xml
> >> ./documentation/book.xml
> >> ./documentation/images/myimage.gif
> >> ./documentation/mypdf.pdf
> >
> >
> > But then what about genuine 'resources' like stylesheets, DTDs and skins?
> > Shouldn't they live under 'documentation' too?
>
> Meta-content? Seems reasonable as you say.
>
> So maybe ./documentation/content/** and ./documentation/resources/**
> is better after all...
>
> >>etc
> >>
> >>One content, one dir.
> >>
> >>IIRC we had already decided on this, so it should be ok to do it.
> >
> >
> > We agreed on the principle, but I can't recall details.
> >
> > About 30 mins ago I made a change whereby everything in
> > src/documentation/content/ is made visible to the sitemap.
>
> Yup, say it.
>
> > Specifically in order to allow sitemap rules like:
> >
> > <map:match pattern="forms/**.pdf">
> > <map:read src="content/forms/{1}.pdf" mime-type="application/pdf"/>
> > </map:match>
> >
> > or:
> >
> > <map:match pattern="static/**/*.html">
> > <map:read src="content/html/{1}/{2}.html" mime-type="text/html"/>
> > </map:match>
> >
> > Does this sound like a reasonable interpretation of "One content, one
> > dir"?
>
> Hmmm... nope, not all yet... we should use the resource-exists action too.
>
> I'll give it a shot.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: documentation/content made available to sitemap (Re: 'broken
link' causes..)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Mon, Nov 04, 2002 at 05:01:35PM +0100, Nicola Ken Barozzi wrote:
>
>>Jeff Turner wrote:
>>[...]
>>
>>>While I'm clarifying.. what's the difference between a 'resource' and
>>>'content'? I'm not too sure.. I think 'resources' are things like XSLT
>>>stylesheets. Not something served up to the user, whereas 'content' is.
>>>By that rule, images should be in content/, not resources/.
>>>
>>>What do people think about changing that?
>>
>>Put the sources in ./documentation/**
>>
>>So we have
>>
>> ./documentation/index.xml
>> ./documentation/book.xml
>> ./documentation/images/myimage.gif
>> ./documentation/mypdf.pdf
>
>
> But then what about genuine 'resources' like stylesheets, DTDs and skins?
> Shouldn't they live under 'documentation' too?
Meta-content? Seems reasonable as you say.
So maybe ./documentation/content/** and ./documentation/resources/**
is better after all...
>>etc
>>
>>One content, one dir.
>>
>>IIRC we had already decided on this, so it should be ok to do it.
>
>
> We agreed on the principle, but I can't recall details.
>
> About 30 mins ago I made a change whereby everything in
> src/documentation/content/ is made visible to the sitemap.
Yup, say it.
> Specifically in order to allow sitemap rules like:
>
> <map:match pattern="forms/**.pdf">
> <map:read src="content/forms/{1}.pdf" mime-type="application/pdf"/>
> </map:match>
>
> or:
>
> <map:match pattern="static/**/*.html">
> <map:read src="content/html/{1}/{2}.html" mime-type="text/html"/>
> </map:match>
>
> Does this sound like a reasonable interpretation of "One content, one
> dir"?
Hmmm... nope, not all yet... we should use the resource-exists action too.
I'll give it a shot.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
documentation/content made available to sitemap (Re: 'broken link' causes..)
Posted by Jeff Turner <je...@apache.org>.
On Mon, Nov 04, 2002 at 05:01:35PM +0100, Nicola Ken Barozzi wrote:
>
> Jeff Turner wrote:
> [...]
> >While I'm clarifying.. what's the difference between a 'resource' and
> >'content'? I'm not too sure.. I think 'resources' are things like XSLT
> >stylesheets. Not something served up to the user, whereas 'content' is.
> >By that rule, images should be in content/, not resources/.
> >
> >What do people think about changing that?
>
> Put the sources in ./documentation/**
>
> So we have
>
> ./documentation/index.xml
> ./documentation/book.xml
> ./documentation/images/myimage.gif
> ./documentation/mypdf.pdf
But then what about genuine 'resources' like stylesheets, DTDs and skins?
Shouldn't they live under 'documentation' too?
> etc
>
> One content, one dir.
>
> IIRC we had already decided on this, so it should be ok to do it.
We agreed on the principle, but I can't recall details.
About 30 mins ago I made a change whereby everything in
src/documentation/content/ is made visible to the sitemap.
Specifically in order to allow sitemap rules like:
<map:match pattern="forms/**.pdf">
<map:read src="content/forms/{1}.pdf" mime-type="application/pdf"/>
</map:match>
or:
<map:match pattern="static/**/*.html">
<map:read src="content/html/{1}/{2}.html" mime-type="text/html"/>
</map:match>
Does this sound like a reasonable interpretation of "One content, one
dir"?
--Jeff
Re: 'broken link' causes..
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
[...]
> While I'm clarifying.. what's the difference between a 'resource' and
> 'content'? I'm not too sure.. I think 'resources' are things like XSLT
> stylesheets. Not something served up to the user, whereas 'content' is.
> By that rule, images should be in content/, not resources/.
>
> What do people think about changing that?
Put the sources in ./documentation/**
So we have
./documentation/index.xml
./documentation/book.xml
./documentation/images/myimage.gif
./documentation/mypdf.pdf
etc
One content, one dir.
IIRC we had already decided on this, so it should be ok to do it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: 'broken link' causes..
Posted by Jeff Turner <je...@apache.org>.
On Tue, Nov 05, 2002 at 02:42:12AM +1100, Jeff Turner wrote:
> On Tue, Nov 05, 2002 at 01:23:21AM +1100, Jeff Turner wrote:
> > On Mon, Nov 04, 2002 at 06:35:11AM -0500, Rodent of Unusual Size wrote:
> > The Forrest sitemap is in xml-forrest/src/resources/conf/sitemap.xmap:
> >
> > http://cvs.apache.org/viewcvs.cgi/xml-forrest/src/resources/conf/sitemap.xmap?rev=HEAD&content-type=text/vnd.viewcvs-markup
> >
> > A full description of it is at:
> >
> > http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html
> >
> > The sitemap is like a switchboard for incoming requests. The problem in
> > incubator-site is that you've got this link:
> >
> > <link href="forms/ASF_Contributor_License_2_form.pdf"
> >
> > Which matches this sitemap rule:
> >
> > <map:match pattern="**.pdf">
> > <map:generate src="content/xdocs/{1}.xml"/>
> > <map:transform
> > src="skins/{defaults:skin}/xslt/fo/document2fo.xsl"/>
> > <map:serialize type="fo2pdf"/>
> > </map:match>
> >
> > which tries to generate a PDF from
> > content/xdocs/forms/ASF_Contributor_License_2_form.xml
>
> Continuing on from this..
>
> The solution is to add a custom sitemap rule for "forms/*.pdf", and put
> it before the more general "**.pdf" rule ('**' matches subdirectories).
>
> So, to fix incubator-site:
>
> - Update your xml-forrest (I've just added a fix to enable this stuff)
> - Run './build.sh' to regen the shbat distribution
> - Copy xml-forrest/src/resources/conf/sitemap.xmap to
> incubator-site/src/documentation.
Correction:
incubator-site/src/documentation/sitemap.xmap.
> - Edit incubator-site/src/documentation, and add the following sitemap
> rule before the "**.pdf" one listed above:
Again, should be incubator-site/src/documentation/sitemap.xmap
> <map:match pattern="forms/**.pdf">
> <map:read src="content/forms/{1}.pdf" mime-type="application/pdf"/>
> </map:match>
>
> - Move incubator-site/src/documentation/resources/forms to
> src/documentation/content/forms
While I'm clarifying.. what's the difference between a 'resource' and
'content'? I'm not too sure.. I think 'resources' are things like XSLT
stylesheets. Not something served up to the user, whereas 'content' is.
By that rule, images should be in content/, not resources/.
What do people think about changing that?
--Jeff
Re: 'broken link' causes..
Posted by Jeff Turner <je...@apache.org>.
On Tue, Nov 05, 2002 at 01:23:21AM +1100, Jeff Turner wrote:
> On Mon, Nov 04, 2002 at 06:35:11AM -0500, Rodent of Unusual Size wrote:
> The Forrest sitemap is in xml-forrest/src/resources/conf/sitemap.xmap:
>
> http://cvs.apache.org/viewcvs.cgi/xml-forrest/src/resources/conf/sitemap.xmap?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
> A full description of it is at:
>
> http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html
>
> The sitemap is like a switchboard for incoming requests. The problem in
> incubator-site is that you've got this link:
>
> <link href="forms/ASF_Contributor_License_2_form.pdf"
>
> Which matches this sitemap rule:
>
> <map:match pattern="**.pdf">
> <map:generate src="content/xdocs/{1}.xml"/>
> <map:transform
> src="skins/{defaults:skin}/xslt/fo/document2fo.xsl"/>
> <map:serialize type="fo2pdf"/>
> </map:match>
>
> which tries to generate a PDF from
> content/xdocs/forms/ASF_Contributor_License_2_form.xml
Continuing on from this..
The solution is to add a custom sitemap rule for "forms/*.pdf", and put
it before the more general "**.pdf" rule ('**' matches subdirectories).
So, to fix incubator-site:
- Update your xml-forrest (I've just added a fix to enable this stuff)
- Run './build.sh' to regen the shbat distribution
- Copy xml-forrest/src/resources/conf/sitemap.xmap to
incubator-site/src/documentation.
- Edit incubator-site/src/documentation, and add the following sitemap
rule before the "**.pdf" one listed above:
<map:match pattern="forms/**.pdf">
<map:read src="content/forms/{1}.pdf" mime-type="application/pdf"/>
</map:match>
- Move incubator-site/src/documentation/resources/forms to
src/documentation/content/forms
- Run 'forrest' in incubator-site/, and the broken link should disappear.
Just to be clear: the incubator-site sitemap should differ from the
standard Forrest one as follows:
--- /home/jeff/apache/xml/xml-forrest/src/resources/conf/sitemap.xmap 2002-11-05 01:45:24.000000000 +1100
+++ src/documentation/sitemap.xmap 2002-11-05 02:25:22.000000000 +1100
@@ -406,6 +406,10 @@
<map:serialize type="fo2pdf"/>
</map:match>
+ <map:match pattern="forms/**.pdf">
+ <map:read src="content/forms/{1}.pdf" mime-type="application/pdf"/>
+ </map:match>
+
<map:match pattern="**.pdf">
<map:generate src="content/xdocs/{1}.xml"/>
<map:transform src="skins/{defaults:skin}/xslt/fo/document2fo.xsl"/>
Incidentally, this is also how one could generate .htaccess files, with a rule
like:
<map:match pattern="**/.htaccess">
<map:read src="content/xdocs/.htaccess"/>
</map:match>
I'll write up this info tomorrow and add it to the site. Thanks for being a
model user, not accepting my half-assed reply ;P I'm sure lots of other people
bang their heads against this.
--Jeff
PS: Once it's all working, try typing 'forrest run', and then point a browser
at http://localhost:8888/. Any content edited in build/webapp/content/xdocs is
instantly rendered in the browser, making page development much faster.
Re: 'broken link' causes..
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
* On 2002-11-04 at 10:26,
Nicola Ken Barozzi <ni...@apache.org> excited the electrons to say:
>
> For istance, is I have a stuff.pdf and a stuff.xml, and I ask for
> stuff.pdf, I only get one of the two files, depending on which comes
> first in the sitemap rules.
ew. well, then, the user needs to be able to control this. by
default, in the above case, i would recommend that the stuff.pdf be
copied, and a warning that 'stuff.xml could not be rendered into pdf;
you already have a stuff.pdf file in <path>'. since the pdf rendering
is a bonus feature, rather than explicitly requested, it definitely
should be the sacrificial victim in cases of conflict such as this.
automating things is cool. automatically making intelligent choices
when presented with dilemmas is cooler. allowing the user to dictate
your choices is cooler still.
Re: 'broken link' causes..
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Rodent of Unusual Size wrote:
> * On 2002-11-04 at 09:46,
> Jeff Turner <je...@apache.org> excited the electrons to say:
>
>>The sitemap is like a switchboard for incoming requests. The problem in
>>incubator-site is that you've got this link:
>>
>> <link href="forms/ASF_Contributor_License_2_form.pdf"
>>
>>Which matches this sitemap rule:
>>
>><map:match pattern="**.pdf">
>> <map:generate src="content/xdocs/{1}.xml"/>
>> <map:transform
>> src="skins/{defaults:skin}/xslt/fo/document2fo.xsl"/>
>> <map:serialize type="fo2pdf"/>
>></map:match>
>>
>>which tries to generate a PDF from
>>content/xdocs/forms/ASF_Contributor_License_2_form.xml
>
>
> thank you for the expanded explanation; i feel much less baffled now.
>
> am i off the wall, or would it be reasonable for *all* such rules to
> at least check to see whether the transformation needs to be done
> before trying it? i don't know from xsl, but pseudo-code:
>
> <map:match pattern="**.pdf">
> <if -e "content/xdocs/{1}.pdf">
> <copy file>
> <else>
> <map:generate src="content/xdocs/{1}.xml"/>
> <map:transform
> src="skins/{defaults:skin}/xslt/fo/document2fo.xsl"/>
> <map:serialize type="fo2pdf"/>
> </if>
> </map:match>
Yup, this has been discussed recently, but basically it introduces a
non-linear correspondence between the input and the output URI spaces,
as you have also asked.
For istance, is I have a stuff.pdf and a stuff.xml, and I ask for
stuff.pdf, I only get one of the two files, depending on which comes
first in the sitemap rules.
Jeff, do you remember what conclusion we came to?
These weeks have been so hectic I forgot :-S
> i notice another problematic thing about the transformation rule: it
> assumes the source is under content/xdocs/ -- which doesn't work in my
> case, because the source pdf is in resources/forms/ instead.
Hmmm... this is about the outer-resources "mounting" and linkmap we
talked about too... gotta finalize...
> i have fallen afoul of the mismatch of structure between the input and
> output tree, as i saw discussed last night.
We should fix this.
> am i trying to warp forrest to do things is isn't designed/intended to
> do, or are my comments useful and maybe can help improve things?
You rock, man, you've given us more useful feedback in three days than
others in three months! :-)
> i've
> jumped right in because of some things nicola said, so perhaps my
> expectations are mis-set..
Exactly what we need: to understand what expectations of the users are
and meet them with the least possible mismatch.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: 'broken link' causes..
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
* On 2002-11-04 at 09:46,
Jeff Turner <je...@apache.org> excited the electrons to say:
>
> The sitemap is like a switchboard for incoming requests. The problem in
> incubator-site is that you've got this link:
>
> <link href="forms/ASF_Contributor_License_2_form.pdf"
>
> Which matches this sitemap rule:
>
> <map:match pattern="**.pdf">
> <map:generate src="content/xdocs/{1}.xml"/>
> <map:transform
> src="skins/{defaults:skin}/xslt/fo/document2fo.xsl"/>
> <map:serialize type="fo2pdf"/>
> </map:match>
>
> which tries to generate a PDF from
> content/xdocs/forms/ASF_Contributor_License_2_form.xml
thank you for the expanded explanation; i feel much less baffled now.
am i off the wall, or would it be reasonable for *all* such rules to
at least check to see whether the transformation needs to be done
before trying it? i don't know from xsl, but pseudo-code:
<map:match pattern="**.pdf">
<if -e "content/xdocs/{1}.pdf">
<copy file>
<else>
<map:generate src="content/xdocs/{1}.xml"/>
<map:transform
src="skins/{defaults:skin}/xslt/fo/document2fo.xsl"/>
<map:serialize type="fo2pdf"/>
</if>
</map:match>
i notice another problematic thing about the transformation rule: it
assumes the source is under content/xdocs/ -- which doesn't work in my
case, because the source pdf is in resources/forms/ instead.
i have fallen afoul of the mismatch of structure between the input and
output tree, as i saw discussed last night.
am i trying to warp forrest to do things is isn't designed/intended to
do, or are my comments useful and maybe can help improve things? i've
jumped right in because of some things nicola said, so perhaps my
expectations are mis-set..
Re: 'broken link' causes..
Posted by Jeff Turner <je...@apache.org>.
On Mon, Nov 04, 2002 at 06:35:11AM -0500, Rodent of Unusual Size wrote:
> Jeff Turner wrote:
> >
> > On Mon, Nov 04, 2002 at 05:02:32AM -0500, Rodent of Unusual Size wrote:
> > > this 'broken link' stuff is really starting to frost my pumpkin.. what
> > > the flying moose ears are the possible causes, and how can i get
> > > forrest to tell me in more detail which one applies?
All the 'rules' in Forrest are in the sitemap. It's the key file that
the whole of Forrest is based on. It's also Cocoon's main claim to fame:
that you can manage a whole site's URI space in a single file.
The Forrest sitemap is in xml-forrest/src/resources/conf/sitemap.xmap:
http://cvs.apache.org/viewcvs.cgi/xml-forrest/src/resources/conf/sitemap.xmap?rev=HEAD&content-type=text/vnd.viewcvs-markup
A full description of it is at:
http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html
The sitemap is like a switchboard for incoming requests. The problem in
incubator-site is that you've got this link:
<link href="forms/ASF_Contributor_License_2_form.pdf"
Which matches this sitemap rule:
<map:match pattern="**.pdf">
<map:generate src="content/xdocs/{1}.xml"/>
<map:transform
src="skins/{defaults:skin}/xslt/fo/document2fo.xsl"/>
<map:serialize type="fo2pdf"/>
</map:match>
which tries to generate a PDF from
content/xdocs/forms/ASF_Contributor_License_2_form.xml
More generally, when you see a broken link, it's because the sitemap:
a) doesn't have a rule to create the referred-to file
b) has a sitemap rule, but it's inappropriate (as above), or the raw content
isn't visible to the sitemap
> > > so far it seems
> > > to varf with one on *any* non-.xml file i try to include, such as .pdf
> > > or verbatim .html.
Yes, because **.html and **.pdf both have sitemap rules, generating HTML and
PDF files respectively from XML source, not from the hard disk.
> > It was a bug in the tab system, now fixed. Here's output from
> > incubator-site:
>
> that doesn't answer the question. also, i don't see what your output
> is supposed to be showing, pre-fix or post-fix:
Post-fix..
> > -> [broken link] forms/ASF_Contributor_License_2_form.pdf <-
> that's exactly [part of] my complaint. *why* is it broken? no explanation
> is given, and i haven't found a troubleshooting docco yet..
Sorry for missing the point of your question..
I'll post a solution/workaround just as soon as I get it working locally.
--Jeff
Re: 'broken link' causes..
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Jeff Turner wrote:
>
> On Mon, Nov 04, 2002 at 05:02:32AM -0500, Rodent of Unusual Size wrote:
> > this 'broken link' stuff is really starting to frost my pumpkin.. what
> > the flying moose ears are the possible causes, and how can i get
> > forrest to tell me in more detail which one applies? so far it seems
> > to varf with one on *any* non-.xml file i try to include, such as .pdf
> > or verbatim .html.
>
> It was a bug in the tab system, now fixed. Here's output from
> incubator-site:
that doesn't answer the question. also, i don't see what your output
is supposed to be showing, pre-fix or post-fix:
> -> [broken link] forms/ASF_Contributor_License_2_form.pdf <-
that's exactly [part of] my complaint. *why* is it broken? no explanation
is given, and i haven't found a troubleshooting docco yet..
Re: 'broken link' causes..
Posted by Jeff Turner <je...@apache.org>.
On Mon, Nov 04, 2002 at 05:02:32AM -0500, Rodent of Unusual Size wrote:
> this 'broken link' stuff is really starting to frost my pumpkin.. what
> the flying moose ears are the possible causes, and how can i get
> forrest to tell me in more detail which one applies? so far it seems
> to varf with one on *any* non-.xml file i try to include, such as .pdf
> or verbatim .html.
It was a bug in the tab system, now fixed. Here's output from
incubator-site:
Setup... done.
Initializing... ready, let's go :-)
^[ * [31] index.html
* [0] skin/page.css
* [0] skin/images/spacer.gif
* [0] skin/breadcrumbs.js
* [0] images/group-logo.gif
* [0] images/project-logo.gif
* [0] skin/images/tabSel-left.gif
* [0] skin/images/tabSel-right.gif
* [0] skin/images/tab-left.gif
* [22] drafts/index.html
* [0] skin/images/tab-right.gif
* [21] projects/index.html
* [31] bylaws.html
* [31] resolution.html
* [31] whoweare.html
* [32] changes.html
* [31] todo.html
* [31] process.html
* [31] theapacheway.html
* [29] scrapbook.html
* [22] drafts/glossary.html
* [0]
-> [broken link] forms/ASF_Contributor_License_2_form.pdf <-
* [0] skin/images/menu-left.gif
* [0] skin/images/menu-right.gif
* [0] index.pdf
* [0] skin/images/printer.gif
* [0] skin/images/label.gif
* [0] skin/images/page.gif
* [0] skin/images/chapter.gif
* [0] skin/images/chapter_open.gif
* [0] skin/images/current.gif
* [0] /favicon.ico
* [0] drafts/index.pdf
* [0] projects/index.pdf
* [0] bylaws.pdf
* [0] resolution.pdf
* [0] whoweare.pdf
* [0] changes.pdf
* [0] images/add.jpg
* [0] todo.pdf
* [0] process.pdf
* [0] theapacheway.pdf
* [0] drafts/glossary.pdf
disposing... done.
--Jeff