You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/06/12 09:55:58 UTC
Cleaning Forrest source directory madness
I'm looking into using XHTML 2.0, and now it seems to me that the
current documentation/ directory layout is confusing at best. To reduce
confusion I was obliged to use the default layout of Forrest in all my
projects.
IIRC I had started with that layout in the beginning, with the following
meaning:
content all stuff that has to be "digested" by Forrest
xdocs xml document-dtd files
images (added later) images that refer to the dir xdocs
-other-
resources all stuff that has to be referenced as-is
images images that have a global use in all pages
-other-
The idea with resources, was that they would be referencable as local to
the current (.) dir even if the were not.
So a resource that was in
resources/images/image.gif
could be called from:
http://site/image.gif
http://site/images/image.gif
http://site/any/path/and/then/image.gif
That was the initial meaning of resource. Something to remain as-is that
was referencable anywhere, both conceptually and in the path.
Now we have the the content/ dir can contain as-is content, and that
html files to process have to be separated by different extensions.
The problemn with the plain content/ dir is that the dir space of xdocs
and content are not separate, and create a nesting that is not there
conceptually.
But the biggest problem is with the html files in xdocs, that are *not*
processed. That means that the xdocs dir, that processes xml files, can
contain html files that it does not process and ihtml files that it
processes. And I still am not sure it's this way.
This was the result of two different dir management visions, the
-separate filetypes in dirs- one and -keep all files in the same
dirspace-. The problem is not that either approach is inherently flawed,
but that they are both applied not consistently.
Hence, I'd like to see a better separation, but I'm not sure how to do
it. Here is a first proposal:
content all stuff that has to be "digested" by Forrest
mixed all "digestable" things "mixed"
xdocs xml document-dtd files
images (added later) images that refer to the dir xdocs
-other-
resources all stuff that has to be referenced as-is
mixed all "non-digestable" things "mixed"
images images that have a global use in all pages
-other-
Here is another:
two separate scenarion:
content all stuff that has to be "digested" by Forrest, "mixed"
resources all stuff that has to be referenced as-is
content all stuff that has to be "digested" by Forrest
xdocs xml document-dtd files
images (added later) images that refer to the dir xdocs
-other-
resources all stuff that has to be referenced as-is
images images that have a global use in all pages
-other-
Ideas?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cleaning Forrest source directory madness
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
>
> Juan Jose, what you ask is exactly what I have been asking to have since
> some months now. But some developers feel that for the it's better to
> divide content in directories.
>
would you mind pointing to that discussion?, I could not find it on the
mailing list.
Is performance the main reason?
> My proposal is made to try and take care of both uses, so that you can
> decide to divide by directories or keep all together.
>
Well, I am not sure about which uses do you refer. I would like to see
this to be real:
http://xml.apache.org/forrest/#User-friendly
Easy and simple, the second point talks about edit presentation-neutral
content, so only the content that is presentation neutral should go to
the content directory.
I would define content images in cases similiar to this one :
/about/logo.xml with a <img src="images/logo.png"/>
Mainly because you talk about the logo itself. But if you have <img
src="images/logo.png"/> in all the pages then it belongs to the skin
unless you only talk about the logo in your site :-)
Before we add images to the content directory we need to ask ourselves
if there are really content or if belongs really to the presentation layer.
Maybe this problem raise because we have not got a way to customize the
skin or look and feel based on the resource ie.: /parnerts/*. that
would be a diferent issue.
But as we say on the site. By separating content from presentation makes
things easier.
Cheers
Cheche
Re: Cleaning Forrest source directory madness
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote, On 13/06/2003 4.20:
> Nicola,
>
> I like that someone mention that mess, it is a bit confusin, but I am
> not sure about the proposal. Your proposal seems to create more
> complexity than it was.
hehehe
>> Ideas?
>>
>
> I would like to remove all directories, so users are free to create the
> struture they feel is best.
>
> so what I got in mind is this:
>
> http://site/image.png
> If that file exists then give it as raw, if not process image.svg.
>
> Is this posible to do so? I saw this, but I am not 100% sure:
> <map:match pattern="**.png">
> <map:act type="resource-exists">
>
Juan Jose, what you ask is exactly what I have been asking to have since
some months now. But some developers feel that for the it's better to
divide content in directories.
My proposal is made to try and take care of both uses, so that you can
decide to divide by directories or keep all together.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cleaning Forrest source directory madness
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
I like that someone mention that mess, it is a bit confusin, but I am
not sure about the proposal. Your proposal seems to create more
complexity than it was.
>
> Ideas?
>
I would like to remove all directories, so users are free to create the
struture they feel is best.
so what I got in mind is this:
http://site/image.png
If that file exists then give it as raw, if not process image.svg.
Is this posible to do so? I saw this, but I am not 100% sure:
<map:match pattern="**.png">
<map:act type="resource-exists">
Cheers,
Cheche
Re: Cleaning Forrest source directory madness
Posted by MAISONOBE Luc <lu...@c-s.fr>.
Nicola Ken Barozzi wrote :
> Here is a first proposal:
[snip]
> Here is another:
[snip]
I don't understand what you mean by "mixed" in your first proposal and
where the corresponding files would go in the second approach, in the
-other- directories (html, ...) ? If this is the case, what is the
-other- directories in the first approach for ?
Another small remark, shouldn't the "images" directories renamed
something like "global" or "global-scope" ? This would help understand
the feature you explain and allow to put some any file type there like
various scripts, or text files, or animations, or sound files or
anything people would like to access from anywhere in their site.
Luc
Re: Cleaning Forrest source directory madness
Posted by Jeff Turner <je...@apache.org>.
On Thu, Jun 12, 2003 at 02:38:17PM +0200, Nicola Ken Barozzi wrote:
...
> >>IIRC I had started with that layout in the beginning, with the following
> >>meaning:
...
> >> resources all stuff that has to be referenced as-is
> >> images images that have a global use in all pagek
...
> >But now that we have site.xml and indirect linking, how about this
> >instead:
> >
> ><figure src="img:project-logo">
> >
> >Where 'img:project-logo' is valid anywhere,
> >
> >In the JIRA docs, the site.xml file has an <images> section, and a 'img'
> >module that looks in there, in the same way as 'ext' looks in
> ><external-refs>. Works fairly decently.
>
> Not bad.
>
> But the main reason why it was put there was to make it easy to put
> javascripts or skin images, so IIUC it's a different use-case...
Oh well, currently resources/images/* is served through the images/*
URLs, and all skins/XSLTs add the ..'s as necessary anyway, to prevent
multiple copies of the file being created.
--Jeff
Re: Cleaning Forrest source directory madness
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 12/06/2003 13.58:
> On Thu, Jun 12, 2003 at 09:55:58AM +0200, Nicola Ken Barozzi wrote:
>
>>I'm looking into using XHTML 2.0, and now it seems to me that the
>>current documentation/ directory layout is confusing at best. To reduce
>>confusion I was obliged to use the default layout of Forrest in all my
>>projects.
>>
>>IIRC I had started with that layout in the beginning, with the following
>>meaning:
>>
>> content all stuff that has to be "digested" by Forrest
>> xdocs xml document-dtd files
>> images (added later) images that refer to the dir xdocs
>> -other-
>> resources all stuff that has to be referenced as-is
>> images images that have a global use in all pages
>> -other-
>>
>>The idea with resources, was that they would be referencable as local to
>>the current (.) dir even if the were not.
>>So a resource that was in
>>
>> resources/images/image.gif
>>
>>could be called from:
>>
>> http://site/image.gif
>> http://site/images/image.gif
>> http://site/any/path/and/then/image.gif
>
>
> Oh, didn't know that. Always wondered why images weren't content ;)
Hehehe
Resources are content, only more "static"; that's how I see the name,
probably it's my misunderstanding of the meaning.
> Makes sense though.
>
> But now that we have site.xml and indirect linking, how about this
> instead:
>
> <figure src="img:project-logo">
>
> Where 'img:project-logo' is valid anywhere,
>
> In the JIRA docs, the site.xml file has an <images> section, and a 'img'
> module that looks in there, in the same way as 'ext' looks in
> <external-refs>. Works fairly decently.
Not bad.
But the main reason why it was put there was to make it easy to put
javascripts or skin images, so IIUC it's a different use-case...
>>That was the initial meaning of resource. Something to remain as-is that
>>was referencable anywhere, both conceptually and in the path.
>
> Well it's not a good idea to have it *literally* in the output path,
> because then you get one copy per directory, which is wasteful.
Yup, right. Link rewriting is needed.
> I've run out of time.. will parse the rest tomorrow.
Cool.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cleaning Forrest source directory madness
Posted by Jeff Turner <je...@apache.org>.
On Thu, Jun 12, 2003 at 09:55:58AM +0200, Nicola Ken Barozzi wrote:
>
> I'm looking into using XHTML 2.0, and now it seems to me that the
> current documentation/ directory layout is confusing at best. To reduce
> confusion I was obliged to use the default layout of Forrest in all my
> projects.
>
> IIRC I had started with that layout in the beginning, with the following
> meaning:
>
> content all stuff that has to be "digested" by Forrest
> xdocs xml document-dtd files
> images (added later) images that refer to the dir xdocs
> -other-
> resources all stuff that has to be referenced as-is
> images images that have a global use in all pages
> -other-
>
> The idea with resources, was that they would be referencable as local to
> the current (.) dir even if the were not.
> So a resource that was in
>
> resources/images/image.gif
>
> could be called from:
>
> http://site/image.gif
> http://site/images/image.gif
> http://site/any/path/and/then/image.gif
Oh, didn't know that. Always wondered why images weren't content ;)
Makes sense though.
But now that we have site.xml and indirect linking, how about this
instead:
<figure src="img:project-logo">
Where 'img:project-logo' is valid anywhere,
In the JIRA docs, the site.xml file has an <images> section, and a 'img'
module that looks in there, in the same way as 'ext' looks in
<external-refs>. Works fairly decently.
> That was the initial meaning of resource. Something to remain as-is that
> was referencable anywhere, both conceptually and in the path.
Well it's not a good idea to have it *literally* in the output path,
because then you get one copy per directory, which is wasteful.
I've run out of time.. will parse the rest tomorrow.
--Jeff
Re: Cleaning Forrest source directory madness
Posted by yachting heritage <co...@yachting-heritage.com>.
can you remove me fro your mailing list list
----- Original Message -----
From: "Jeff Turner" <je...@apache.org>
To: <fo...@xml.apache.org>; <ni...@apache.org>
Sent: Monday, June 16, 2003 10:48 AM
Subject: Re: Cleaning Forrest source directory madness
> On Sun, Jun 15, 2003 at 05:54:57PM +0200, Nicola Ken Barozzi wrote:
> ...
> [snip agreed-on stuff]
> ...
> > About status.xml, having it in the root of the project serves a
> > purpose, but it's more than ugly from other perspectives.
>
> It at least illustrates one point; that eventually we should have the
> Forrest webapp rooted in the project root. That way, we could
> potentially transform anything in the project. In particular, we could
> use qdox/chaperon to do something useful with Java source.
>
> > For example, we should stop creating a file named todo.html out of it,
> > as it should be one source -> one result. Aggregation can be done, but
> > not the opposite.
>
> Why not the opposite?
>
> > Tha said, I still like it this way, there is an advantage to it.
> >
> > Ideas?
>
> ...
> [snip good stuff on images]
> ...
>
> > The only one that will remain is "raw", and it seems that there is a
> > real-life use case for it.
> >
> > Mind me, I would still add a **.* matcher at the end of the
> > content-handling pipeline, so that content/** can still contain
anything.
>
> Sounds good.
>
> > 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, like for example a
> > raw document-dtd xml file.
>
> The more important reason for needing a raw/ directory is that the
> crawler can't crawl the entire URI space, so we need an Ant <copy
> from="...raw/" to="build/site/"> to copy uncrawlable stuff.
>
> > So the content dir is about all content, that Forrest *may* alter.
> > The raw dir is about content that Forrest may *not* alter in any way.
> >
> > I think we agree, no?
>
> Yep.
>
>
> --Jeff
>
>
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory
madness)
Posted by MAISONOBE Luc <lu...@c-s.fr>.
Nicola Ken Barozzi wrote :
> Jeff Turner wrote, On 16/06/2003 13.22:
[snip]
>> - Investigate the bug report that content/*.xml gets parsed when it
>> shouldn't
>
>
> Ah, ok.
If you want a real life example, you can for example take a look at this
raw small xml file :
http://www.spaceroots.org/software/rkcheck/DormandPrince853.xml
When, I regenerate the site, I overwrite the files manually after
forrest has finished, in order to be sure the file sizes I show in the
downloads page are OK, otherwise there are some end of line missing in
the header before the root element (<Runge-Kutta name="Dormand-Prince
8(5,3)"> in this case) and also after the end of this element.
I confirm the file seems to be validated (probably several times),
because I noticed lots of DTD downloads on the site after my tests (I
forgot to declare the DTD in any local catalog).
I feel not comfortable enough with forrest yet to investigate by myself,
but I promise I will try later :-(
Luc
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory
madness)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote, On 16/06/2003 16.13:
...
>> - Speed! Need to haul out the profiler and find out why normal Cocoon
>> CLI rendering is 5-10x faster than Forrest.
>
>
> +1
>
> I don't know if/when I'll have time, but I'll surely want to work on this.
Ok, so I ran hprof on it, with the krysalis-site skin ans PDFS, and it
seems to tell me that most of the time is used in - guess what - in Xalan.
So I though, hey, it's our bl--dy skin that sucks, with wierd templates.
Guess what, this is what I got (all with PDF generation on):
template: 31 seconds
krysalis: 35 seconds
forrest: 34 seconds
forrest-css: 36 seconds
Wait a sec, it's not only the kind of skin then. It's about the number
and types of xsl transformations that it has to go through!
So, what I will have to do now is to do a profile on Cocoon, because the
java one has quite clearly shown that the problem is not in link
translation or other Forrest-specific component, but in the xsl
transformations, where they are, and what they do.
Also, IIUC we are still using the old crawling method, is this correct?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
benchmark website build (Was: Forrest 0.5 outstanding issues)
Posted by David Crossley <cr...@indexgeo.com.au>.
We already have a website in Forrest CVS that could perhaps be used for
this. The src/resources/fresh-site is the stuff that creates a new
project when you do 'forrest seed'. This also currently gets built by
Forrestbot. So if we make a few enhancements as Cheche suggests, then
this site could remain unchanged and be used for testing.
http://forrestbot.cocoondev.org/site/xml-forrest-template
Surely it would not be hard for "forrestbot" to append timing info into
a log file.
--David
Juan Jose Pablos wrote:
> Jeff Turner wrote:
> >Juan Jose Pablos wrote:
> >>Nicola Ken wrote:
> >
> > ...
> >
> >>>I don't know if/when I'll have time, but I'll surely want to work on this.
> >>>
> >>>We could also define a test site that gets generated every night and
> >>>shows us if/how performance is affected. I can use my server here to do
> >>>it since at night it doesn't do anything else, all I need is a test
> >>>site. What about taking our site now, freezing it, and checking it in a
> >>>test dir, so it remains as the base of the tests? Or IYHO is there a
> >>>better real-life test site we could use?
> >>>
> >>
> >>I like that, can we just create a test site with test cases?, in this
> >>way, we make sure that things still working.
> >
> > We'd just need to log times for the sites on
> > http://forrestbot.cocoondev.org/.
> >
> > --Jeff
>
> We can not compare that, because:
>
> What about if you add/remove more pages?
> What about if you modify the skin with less/more features?
>
> If you want to test the performance on time, then you have to create
> test cases that does not change that much.
> I got a feew examples ( please add more):
>
> table of 50 elements.
> render a svg logo
> Display a page with the maximum amount of elements posible for these
> diferent source formats:
>
> docv12 -> html
> docbook-> html
> wiki -> html
> faq -> html
> howto -> html
> rss -> html
>
> and for a diferent output:
>
> docv12 -> pdf
>
>
> I can help on the creation of the pages, but I am not sure how to achive
> the mesaure of that.
>
> Cheers
>
> Cheche
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory
madness)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
Jeff Turner wrote:
> On Mon, Jun 16, 2003 at 05:37:40PM +0200, Juan Jose Pablos wrote:
>
>>Nicola,
>
> ...
>
>>>I don't know if/when I'll have time, but I'll surely want to work on this.
>>>
>>>We could also define a test site that gets generated every night and
>>>shows us if/how performance is affected. I can use my server here to do
>>>it since at night it doesn't do anything else, all I need is a test
>>>site. What about taking our site now, freezing it, and checking it in a
>>>test dir, so it remains as the base of the tests? Or IYHO is there a
>>>better real-life test site we could use?
>>>
>>
>>I like that, can we just create a test site with test cases?, in this
>>way, we make sure that things still working.
>
>
> We'd just need to log times for the sites on
> http://forrestbot.cocoondev.org/.
>
> --Jeff
We can not compare that, because:
What about if you add/remove more pages?
What about if you modify the skin with less/more features?
If you want to test the performance on time, then you have to create
test cases that does not change that much.
I got a feew examples ( please add more):
table of 50 elements.
render a svg logo
Display a page with the maximum amount of elements posible for these
diferent source formats:
docv12 -> html
docbook-> html
wiki -> html
faq -> html
howto -> html
rss -> html
and for a diferent output:
docv12 -> pdf
I can help on the creation of the pages, but I am not sure how to achive
the mesaure of that.
Cheers
Cheche
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory madness)
Posted by Jeff Turner <je...@apache.org>.
On Mon, Jun 16, 2003 at 05:37:40PM +0200, Juan Jose Pablos wrote:
> Nicola,
...
> >I don't know if/when I'll have time, but I'll surely want to work on this.
> >
> >We could also define a test site that gets generated every night and
> >shows us if/how performance is affected. I can use my server here to do
> >it since at night it doesn't do anything else, all I need is a test
> >site. What about taking our site now, freezing it, and checking it in a
> >test dir, so it remains as the base of the tests? Or IYHO is there a
> >better real-life test site we could use?
> >
>
> I like that, can we just create a test site with test cases?, in this
> way, we make sure that things still working.
We'd just need to log times for the sites on
http://forrestbot.cocoondev.org/.
--Jeff
> Cheers
>
> Cheche
>
>
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory
madness)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
>> - Speed! Need to haul out the profiler and find out why normal Cocoon
>> CLI rendering is 5-10x faster than Forrest.
>
>
> +1
>
> I don't know if/when I'll have time, but I'll surely want to work on this.
>
> We could also define a test site that gets generated every night and
> shows us if/how performance is affected. I can use my server here to do
> it since at night it doesn't do anything else, all I need is a test
> site. What about taking our site now, freezing it, and checking it in a
> test dir, so it remains as the base of the tests? Or IYHO is there a
> better real-life test site we could use?
>
I like that, can we just create a test site with test cases?, in this
way, we make sure that things still working.
Cheers
Cheche
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory
madness)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
yachting heritage wrote, On 16/06/2003 16.28:
> stop sending me message
Send a blank mail to:
forrest-dev-unsubscribe@xml.apache.org
and then reply to the confirmation message.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory madness)
Posted by yachting heritage <co...@yachting-heritage.com>.
stop sending me message
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
To: <fo...@xml.apache.org>
Sent: Monday, June 16, 2003 3:13 PM
Subject: Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source
directory madness)
>
>
> Jeff Turner wrote, On 16/06/2003 13.22:
> > On Mon, Jun 16, 2003 at 12:02:31PM +0200, Nicola Ken Barozzi wrote:
> ...
> >>I have the right hand side content stuff with the content pipeline
> >>pending too, and the eventual change in descriptors (although if we
> >>first decide as now to use less stuff in them it will be easier later
> >>on). Just to let you know I haven't forgotten it.
> >
> >
> > Yep, neither have I.
> >
> > Though I keep thinking, it's been around 3 months since we did a
release,
> > so we should probably defer all this fun descriptor stuff should be
> > deferred till 0.6.
>
> +1
>
> > We should start a list of things needed for 0.5.. so far I've got:
> >
> > - Document alternative @tab scheme, decide what can be fixed for 0.5
>
> +0
>
> > - Document how aggregate HTML/PDF works
>
> +1 And add the possible link to the skinconf.xml
>
> > - Upgrade Cocoon to get rid of the MIME type bug (eg *.doc becomes
> > *.docnull).
>
> Ok.
>
> > - Investigate the bug report that content/*.xml gets parsed when it
> > shouldn't
>
> Ah, ok.
>
> > - Fix linkrewriter so it is configured once, instead of once per
> > transformer
>
> Ugh, didn't know this,
>
> > - Speed! Need to haul out the profiler and find out why normal Cocoon
> > CLI rendering is 5-10x faster than Forrest.
>
> +1
>
> I don't know if/when I'll have time, but I'll surely want to work on this.
>
> We could also define a test site that gets generated every night and
> shows us if/how performance is affected. I can use my server here to do
> it since at night it doesn't do anything else, all I need is a test
> site. What about taking our site now, freezing it, and checking it in a
> test dir, so it remains as the base of the tests? Or IYHO is there a
> better real-life test site we could use?
>
> Of course, this would not make it run faster, but spot if changes have
> increased-decreased real-life performance.
>
> > Please add..
>
> There was something else but I forgot (honest! ;-)
> I think that the above are more than sufficient for now.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory
madness)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 16/06/2003 13.22:
> On Mon, Jun 16, 2003 at 12:02:31PM +0200, Nicola Ken Barozzi wrote:
...
>>I have the right hand side content stuff with the content pipeline
>>pending too, and the eventual change in descriptors (although if we
>>first decide as now to use less stuff in them it will be easier later
>>on). Just to let you know I haven't forgotten it.
>
>
> Yep, neither have I.
>
> Though I keep thinking, it's been around 3 months since we did a release,
> so we should probably defer all this fun descriptor stuff should be
> deferred till 0.6.
+1
> We should start a list of things needed for 0.5.. so far I've got:
>
> - Document alternative @tab scheme, decide what can be fixed for 0.5
+0
> - Document how aggregate HTML/PDF works
+1 And add the possible link to the skinconf.xml
> - Upgrade Cocoon to get rid of the MIME type bug (eg *.doc becomes
> *.docnull).
Ok.
> - Investigate the bug report that content/*.xml gets parsed when it
> shouldn't
Ah, ok.
> - Fix linkrewriter so it is configured once, instead of once per
> transformer
Ugh, didn't know this,
> - Speed! Need to haul out the profiler and find out why normal Cocoon
> CLI rendering is 5-10x faster than Forrest.
+1
I don't know if/when I'll have time, but I'll surely want to work on this.
We could also define a test site that gets generated every night and
shows us if/how performance is affected. I can use my server here to do
it since at night it doesn't do anything else, all I need is a test
site. What about taking our site now, freezing it, and checking it in a
test dir, so it remains as the base of the tests? Or IYHO is there a
better real-life test site we could use?
Of course, this would not make it run faster, but spot if changes have
increased-decreased real-life performance.
> Please add..
There was something else but I forgot (honest! ;-)
I think that the above are more than sufficient for now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
XSLT editing with emacs (Was: Forrest 0.5 outstanding issues)
Posted by David Crossley <cr...@indexgeo.com.au>.
Leo Simons wrote:
> Jeff Turner wrote:
<snip/>
> >
> > Alternatively, you could.. oh never mind ;)
>
> hehehe. Tried and failed. There is a lot in the xml world I know only a
> little about. Various tools always seem to sprout various vague errors
> (File not found: index.htmlnull, upgrade a library, and it works. Why on
> earth is that?! How does one debug xsl?). I get frustrated all the time!
>
> > :wq!
>
> I am an emacs guy myself ;)
>
> take care,
>
> - Leo
I do not yet use emacs, but i come closer every day.
I recall something that Ovidiu once mentioned that may help.
...
... MARC search ... gee that is a good tool ... quickly found it
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104204885608512
And &deity; bless him!
--David
RE: Forrest 0.5 outstanding issues
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
>
> hehehe. Tried and failed. There is a lot in the xml world I know only a
> little about. Various tools always seem to sprout various vague errors
> (File not found: index.htmlnull, upgrade a library, and it works. Why on
> earth is that?! How does one debug xsl?). I get frustrated all the time!
Usually, the processor spits out explicit error information like the exact
offending thing, the XSL file that it occurs in and the line number. If that
doesn't help there is always divide and conquer :) But the example you cite
does not look like an XSL error.
It would be nice if you could simply run a single (forrest) page
transformation at the command using just the XSL processor (or many
different ones), the XSL and XML source and nothing else. Is this possible?
-Rob
Re: Forrest 0.5 outstanding issues
Posted by Leo Simons <le...@apache.org>.
Jeff Turner wrote:
>> - maven plugin!
>
> Oops, yes, sorry ;)
no worries, mate :D
>> I want you guys on board here.....I'm offering a Free Beer (yes,
>> that's free as in beer) to the entire forrest committer team (to
>> be drunk at my place only, though) if a checked and maybe improved
>> version of this stuff can get a release soon :D
>
> Have you more or less finished working on it?
for now. Everything else that needs doing requires more XSL knowledge
than I have ;)
> Safe to commit to Forrest?
imho.
> Is the most recent version the one living somewhere in Avalon, or the one
> in ~leosimons/..? I'll have a play this w'end.
just synced the two :D
>> - combined DTDs. I use intellij IDEA (who doesn't ;) for editing xml,
>> and it won't eat the chopped up DTDs (with the .mod entity
>> inclusions). It would be cool if forrest shipped with (or put
>> online) a set of merged dtds that can be eaten by tools like this.
>> I believe NekoDTD can be used to do this kind of merge
>> automatically, but I can't get it to do its magic. IANAXKOG (I Am
>> Not An XSL Kind Of Guy).
>
> AFAIK, the reconstitution of a full DTD from entities is done by the XML
> parser. I would have thought IDEA just needs a pointer to the *.dtd
> file. Perhaps it can't resolve the relative paths to *.mod files.
that's what I thought as well, so I added those as "resources" as well.
That didn't work. Simply replacing the entity references with the
content of the .mod files does work properly. Docs are sparse. One could
consider contacting the intellij team of course to get them to figure it
out :D
> Hmm..
> I'll have a play.
>
> Alternatively, you could.. oh never mind ;)
hehehe. Tried and failed. There is a lot in the xml world I know only a
little about. Various tools always seem to sprout various vague errors
(File not found: index.htmlnull, upgrade a library, and it works. Why on
earth is that?! How does one debug xsl?). I get frustrated all the time!
> :wq!
I am an emacs guy myself ;)
take care,
- Leo
Re: Forrest 0.5 outstanding issues
Posted by Jeff Turner <je...@apache.org>.
On Mon, Jun 16, 2003 at 11:13:53PM +0200, Leo Simons wrote:
> Jeff Turner wrote:
> >We should start a list of things needed for 0.5.. so far I've got:
> >
> > - Document alternative @tab scheme, decide what can be fixed for 0.5
> > - Document how aggregate HTML/PDF works
> > - Upgrade Cocoon to get rid of the MIME type bug (eg *.doc becomes
> > *.docnull).
> > - Investigate the bug report that content/*.xml gets parsed when it
> > shouldn't
> > - Fix linkrewriter so it is configured once, instead of once per
> > transformer
> > - Speed! Need to haul out the profiler and find out why normal Cocoon
> > CLI rendering is 5-10x faster than Forrest.
>
> - maven plugin!
Oops, yes, sorry ;)
> I want you guys on board here.....I'm offering a Free Beer (yes,
> that's free as in beer) to the entire forrest committer team (to
> be drunk at my place only, though) if a checked and maybe improved
> version of this stuff can get a release soon :D
Have you more or less finished working on it? Safe to commit to Forrest?
Is the most recent version the one living somewhere in Avalon, or the one
in ~leosimons/..? I'll have a play this w'end.
> - combined DTDs. I use intellij IDEA (who doesn't ;) for editing xml,
> and it won't eat the chopped up DTDs (with the .mod entity
> inclusions). It would be cool if forrest shipped with (or put
> online) a set of merged dtds that can be eaten by tools like this.
> I believe NekoDTD can be used to do this kind of merge
> automatically, but I can't get it to do its magic. IANAXKOG (I Am
> Not An XSL Kind Of Guy).
AFAIK, the reconstitution of a full DTD from entities is done by the XML
parser. I would have thought IDEA just needs a pointer to the *.dtd
file. Perhaps it can't resolve the relative paths to *.mod files. Hmm..
I'll have a play.
Alternatively, you could.. oh never mind ;)
:wq!
--Jeff
> cheers,
>
> - Leo
>
>
Re: Forrest 0.5 outstanding issues
Posted by Leo Simons <le...@apache.org>.
Jeff Turner wrote:
> We should start a list of things needed for 0.5.. so far I've got:
>
> - Document alternative @tab scheme, decide what can be fixed for 0.5
> - Document how aggregate HTML/PDF works
> - Upgrade Cocoon to get rid of the MIME type bug (eg *.doc becomes
> *.docnull).
> - Investigate the bug report that content/*.xml gets parsed when it
> shouldn't
> - Fix linkrewriter so it is configured once, instead of once per
> transformer
> - Speed! Need to haul out the profiler and find out why normal Cocoon
> CLI rendering is 5-10x faster than Forrest.
- maven plugin! I want you guys on board here.....I'm offering
a Free Beer (yes, that's free as in beer) to the entire forrest
committer team (to be drunk at my place only, though) if a
checked and maybe improved version of this stuff can get a release
soon :D
- combined DTDs. I use intellij IDEA (who doesn't ;) for editing xml,
and it won't eat the chopped up DTDs (with the .mod entity
inclusions). It would be cool if forrest shipped with (or put
online) a set of merged dtds that can be eaten by tools like this.
I believe NekoDTD can be used to do this kind of merge
automatically, but I can't get it to do its magic. IANAXKOG (I Am
Not An XSL Kind Of Guy).
cheers,
- Leo
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory madness)
Posted by yachting heritage <co...@yachting-heritage.com>.
remove me from your list
----- Original Message -----
From: "Jeff Turner" <je...@apache.org>
To: <fo...@xml.apache.org>; <ni...@apache.org>
Sent: Monday, June 16, 2003 12:22 PM
Subject: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source
directory madness)
> On Mon, Jun 16, 2003 at 12:02:31PM +0200, Nicola Ken Barozzi wrote:
> > Jeff Turner wrote, On 16/06/2003 11.48:
> > >>About status.xml, having it in the root of the project serves a
> > >>purpose, but it's more than ugly from other perspectives.
> > >
> > >It at least illustrates one point; that eventually we should have the
> > >Forrest webapp rooted in the project root. That way, we could
> > >potentially transform anything in the project. In particular, we could
> > >use qdox/chaperon to do something useful with Java source.
> >
> > You're nasty ;-)
> >
> > I like it, excellent idea! :-)
>
> :)
>
> ...
> > I have the right hand side content stuff with the content pipeline
> > pending too, and the eventual change in descriptors (although if we
> > first decide as now to use less stuff in them it will be easier later
> > on). Just to let you know I haven't forgotten it.
>
> Yep, neither have I.
>
> Though I keep thinking, it's been around 3 months since we did a release,
> so we should probably defer all this fun descriptor stuff should be
> deferred till 0.6.
>
> We should start a list of things needed for 0.5.. so far I've got:
>
> - Document alternative @tab scheme, decide what can be fixed for 0.5
> - Document how aggregate HTML/PDF works
> - Upgrade Cocoon to get rid of the MIME type bug (eg *.doc becomes
> *.docnull).
> - Investigate the bug report that content/*.xml gets parsed when it
> shouldn't
> - Fix linkrewriter so it is configured once, instead of once per
> transformer
> - Speed! Need to haul out the profiler and find out why normal Cocoon
> CLI rendering is 5-10x faster than Forrest.
>
> Please add..
>
>
> --Jeff
>
>
> > --
> > Nicola Ken Barozzi nicolaken@apache.org
> > - verba volant, scripta manent -
> > (discussions get forgotten, just code remains)
> > ---------------------------------------------------------------------
>
>
Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory
madness)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
>
> We should start a list of things needed for 0.5.. so far I've got:
>
> - Document alternative @tab scheme, decide what can be fixed for 0.5
> - Document how aggregate HTML/PDF works
> - Upgrade Cocoon to get rid of the MIME type bug (eg *.doc becomes
> *.docnull).
> - Investigate the bug report that content/*.xml gets parsed when it
> shouldn't
> - Fix linkrewriter so it is configured once, instead of once per
> transformer
> - Speed! Need to haul out the profiler and find out why normal Cocoon
> CLI rendering is 5-10x faster than Forrest.
>
> Please add..
- Libraries using a stable released, this is the list ( I hope I do not
forget any):
batik-all-1.5b5.jar -> 1.5
fop-0.20.5rc3a.jar -> 0.20.5
chaperon-20030407.jar -> wait for 2.2?
jing-20020724.jar -> 20030619?
jtidy-04aug2000r7-dev.jar -> ?? seems dead
sohould we wait two weeks after the released of cocoon 2.1?
Cheers,
Cheche
Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory madness)
Posted by Jeff Turner <je...@apache.org>.
On Mon, Jun 16, 2003 at 12:02:31PM +0200, Nicola Ken Barozzi wrote:
> Jeff Turner wrote, On 16/06/2003 11.48:
> >>About status.xml, having it in the root of the project serves a
> >>purpose, but it's more than ugly from other perspectives.
> >
> >It at least illustrates one point; that eventually we should have the
> >Forrest webapp rooted in the project root. That way, we could
> >potentially transform anything in the project. In particular, we could
> >use qdox/chaperon to do something useful with Java source.
>
> You're nasty ;-)
>
> I like it, excellent idea! :-)
:)
...
> I have the right hand side content stuff with the content pipeline
> pending too, and the eventual change in descriptors (although if we
> first decide as now to use less stuff in them it will be easier later
> on). Just to let you know I haven't forgotten it.
Yep, neither have I.
Though I keep thinking, it's been around 3 months since we did a release,
so we should probably defer all this fun descriptor stuff should be
deferred till 0.6.
We should start a list of things needed for 0.5.. so far I've got:
- Document alternative @tab scheme, decide what can be fixed for 0.5
- Document how aggregate HTML/PDF works
- Upgrade Cocoon to get rid of the MIME type bug (eg *.doc becomes
*.docnull).
- Investigate the bug report that content/*.xml gets parsed when it
shouldn't
- Fix linkrewriter so it is configured once, instead of once per
transformer
- Speed! Need to haul out the profiler and find out why normal Cocoon
CLI rendering is 5-10x faster than Forrest.
Please add..
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
Re: Cleaning Forrest source directory madness
Posted by yachting heritage <co...@yachting-heritage.com>.
can you remove me from your mailing list
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
To: <fo...@xml.apache.org>
Sent: Monday, June 16, 2003 11:02 AM
Subject: Re: Cleaning Forrest source directory madness
>
>
> Jeff Turner wrote, On 16/06/2003 11.48:
> > On Sun, Jun 15, 2003 at 05:54:57PM +0200, Nicola Ken Barozzi wrote:
> > ...
> > [snip agreed-on stuff]
> > ...
> >
> >>About status.xml, having it in the root of the project serves a
> >>purpose, but it's more than ugly from other perspectives.
> >
> > It at least illustrates one point; that eventually we should have the
> > Forrest webapp rooted in the project root. That way, we could
> > potentially transform anything in the project. In particular, we could
> > use qdox/chaperon to do something useful with Java source.
>
> You're nasty ;-)
>
> I like it, excellent idea! :-)
>
> Probably with some site:xxx linking most link problems will vanish, also
> because most links are relative, and the absolute ones go in site.xml.
> We can also work on stuff in the build dir if we want!
> <nasty!>
>
> >>For example, we should stop creating a file named todo.html out of it,
> >>as it should be one source -> one result. Aggregation can be done, but
> >>not the opposite.
> >
> > Why not the opposite?
>
> I have seen users confused by the fact that todo.html comes from
> status.xml, and so does changes.html.
>
> <mad-man>
> Honestly I don't know, I like both the fact that there is a 1-1 mapping
> to source and result, but there are nice things that can be done with
> aggregation and separation. The obvious problem are name clashes, it id
> I add a todo.xml file in the root dir; now I can't, there is the status
> thing. Maybe a status.todo.html or something like it? Dunno, I see an
> inconsistency but can't get out of it.
> Probably the confusion comes out more because of status.xml in the root
> dir than anything else, dunno.
> </mad-man>
>
> >>Tha said, I still like it this way, there is an advantage to it.
> >>
> >>Ideas?
> >
> > ...
> > [snip good stuff on images]
> > ...
> >
> >>The only one that will remain is "raw", and it seems that there is a
> >>real-life use case for it.
> >>
> >>Mind me, I would still add a **.* matcher at the end of the
> >>content-handling pipeline, so that content/** can still contain
anything.
> >
> > Sounds good.
> >
> >>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, like for example a
> >>raw document-dtd xml file.
> >
> > The more important reason for needing a raw/ directory is that the
> > crawler can't crawl the entire URI space, so we need an Ant <copy
> > from="...raw/" to="build/site/"> to copy uncrawlable stuff.
>
> Ok, that's the other side of the coin: I saw it conceptually, you more
> practically. Hehehe.
>
> >>So the content dir is about all content, that Forrest *may* alter.
> >>The raw dir is about content that Forrest may *not* alter in any way.
> >>
> >>I think we agree, no?
> >
> > Yep.
>
> Excellent.
>
> I have the right hand side content stuff with the content pipeline
> pending too, and the eventual change in descriptors (although if we
> first decide as now to use less stuff in them it will be easier later
> on). Just to let you know I haven't forgotten it.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
Re: Cleaning Forrest source directory madness
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 16/06/2003 11.48:
> On Sun, Jun 15, 2003 at 05:54:57PM +0200, Nicola Ken Barozzi wrote:
> ...
> [snip agreed-on stuff]
> ...
>
>>About status.xml, having it in the root of the project serves a
>>purpose, but it's more than ugly from other perspectives.
>
> It at least illustrates one point; that eventually we should have the
> Forrest webapp rooted in the project root. That way, we could
> potentially transform anything in the project. In particular, we could
> use qdox/chaperon to do something useful with Java source.
You're nasty ;-)
I like it, excellent idea! :-)
Probably with some site:xxx linking most link problems will vanish, also
because most links are relative, and the absolute ones go in site.xml.
We can also work on stuff in the build dir if we want!
<nasty!>
>>For example, we should stop creating a file named todo.html out of it,
>>as it should be one source -> one result. Aggregation can be done, but
>>not the opposite.
>
> Why not the opposite?
I have seen users confused by the fact that todo.html comes from
status.xml, and so does changes.html.
<mad-man>
Honestly I don't know, I like both the fact that there is a 1-1 mapping
to source and result, but there are nice things that can be done with
aggregation and separation. The obvious problem are name clashes, it id
I add a todo.xml file in the root dir; now I can't, there is the status
thing. Maybe a status.todo.html or something like it? Dunno, I see an
inconsistency but can't get out of it.
Probably the confusion comes out more because of status.xml in the root
dir than anything else, dunno.
</mad-man>
>>Tha said, I still like it this way, there is an advantage to it.
>>
>>Ideas?
>
> ...
> [snip good stuff on images]
> ...
>
>>The only one that will remain is "raw", and it seems that there is a
>>real-life use case for it.
>>
>>Mind me, I would still add a **.* matcher at the end of the
>>content-handling pipeline, so that content/** can still contain anything.
>
> Sounds good.
>
>>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, like for example a
>>raw document-dtd xml file.
>
> The more important reason for needing a raw/ directory is that the
> crawler can't crawl the entire URI space, so we need an Ant <copy
> from="...raw/" to="build/site/"> to copy uncrawlable stuff.
Ok, that's the other side of the coin: I saw it conceptually, you more
practically. Hehehe.
>>So the content dir is about all content, that Forrest *may* alter.
>>The raw dir is about content that Forrest may *not* alter in any way.
>>
>>I think we agree, no?
>
> Yep.
Excellent.
I have the right hand side content stuff with the content pipeline
pending too, and the eventual change in descriptors (although if we
first decide as now to use less stuff in them it will be easier later
on). Just to let you know I haven't forgotten it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cleaning Forrest source directory madness
Posted by Jeff Turner <je...@apache.org>.
On Sun, Jun 15, 2003 at 05:54:57PM +0200, Nicola Ken Barozzi wrote:
...
[snip agreed-on stuff]
...
> About status.xml, having it in the root of the project serves a
> purpose, but it's more than ugly from other perspectives.
It at least illustrates one point; that eventually we should have the
Forrest webapp rooted in the project root. That way, we could
potentially transform anything in the project. In particular, we could
use qdox/chaperon to do something useful with Java source.
> For example, we should stop creating a file named todo.html out of it,
> as it should be one source -> one result. Aggregation can be done, but
> not the opposite.
Why not the opposite?
> Tha said, I still like it this way, there is an advantage to it.
>
> Ideas?
...
[snip good stuff on images]
...
> The only one that will remain is "raw", and it seems that there is a
> real-life use case for it.
>
> Mind me, I would still add a **.* matcher at the end of the
> content-handling pipeline, so that content/** can still contain anything.
Sounds good.
> 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, like for example a
> raw document-dtd xml file.
The more important reason for needing a raw/ directory is that the
crawler can't crawl the entire URI space, so we need an Ant <copy
from="...raw/" to="build/site/"> to copy uncrawlable stuff.
> So the content dir is about all content, that Forrest *may* alter.
> The raw dir is about content that Forrest may *not* alter in any way.
>
> I think we agree, no?
Yep.
--Jeff
Re: Cleaning Forrest source directory madness
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 15/06/2003 6.23:
> On Sat, Jun 14, 2003 at 04:48:01PM +0200, Nicola Ken Barozzi wrote:
>
>>Jeff Turner wrote, On 14/06/2003 12.47:
>>...
>>
>>>Would it help if we make xdoc processing the default, and put
>>>copied-across content in a special directory:
>>>
>>>content/index.xml
>>>content/raw/foo.html
>>>
>>>Then if we then renamed 'content' to 'xdocs', and moved images/ into
>>>there, we'd have the Maven structure:
>>>
>>>xdocs/*.xml
>>>xdocs/images/*.png
>>>xdocs/raw/foo.html
>>
>>I don't like the name "xdocs" for a dir, but that's really a minor issue.
>
> I don't like it much either, so let me rewrite that as..
>
> documentation/
> content/*.xml
> content/images/*.png
> content/raw/foo.html
Ok.
> I don't know. I think we should do a 0.5 release with things as they are
> currently, and then fix the problem properly in a future release.
+1
> "fix
> properly" meaning, get rid of special purpose directories altogether, and
> let the user partition things however they want. Why try to _increase_
> the amount of special directories in 0.5, when we really want to get rid
> of them all in the future.
Yup.
So we would have use definable (KISS)
content-dir
raw-dir
About status.xml, having it in the root of the project serves a purpose,
but it's more than ugly from other perspectives.
For example, we should stop creating a file named todo.html out of it,
as it should be one source -> one result. Aggregation can be done, but
not the opposite.
Tha said, I still like it this way, there is an advantage to it.
Ideas?
>>I think I'm ok with this. More below.
>>
>>...
>>
>>>How about:
>>>
>>>- Declaring images as 'content', and moving them under content/
>>>- Keep resources for things that don't end up on the final site:
>>>
>>>resources/stylesheets
>>>resources/conf # Sitemaps, etc
>>>resources/lib
>>>resources/classes
>>
>>Hmmm, now it's easy just to copy the resorces dir with the stylesheets
>>and stuff, it would need some changes... but again, it makes sense.
>>
>>Ok, trying to recap and expand your proposal conceptually:
>>
>> documentation
>> content -> model
>> - files to process (1)
>> - files not to process (2)
>> resources -> controller
>> skins -> view
>
>
> That's a nice way to think of it.
:-)
> ...
>
>>What can xdocs contain?
>>
>>- *.xml (documentdtd, faq, changes, todo, status, etc)
>>- *.html (html4, to be tidied)
>>- *.xhtml (xhtml1, xhtml2-dev)
>>- *.wiki
>>- *.png,gif,etc
>
>
> (which makes 'xdocs' a rather bad name)
Ok, we resonate.
>>Shall we negate the possibility of handling images in the xdocs dir? I
>>think no. Also because this does not preclude someone from putting them
>>in the /images/ dir and getting them from there. I'd do just that for
>>Forrest BTW.
>
> Sorry, I didn't follow. What /images/ directory? For images, all I
> suggest is that they be reclassified as content:
>
> content/images/*.png
What I'm trying to say is that if I have an image in
content/images/myimage.png
And I want to reference it in
content/index.xml
and I use the following link (as IIUC is now)
images/myimage.png
Then the images dir is not a special purpose directory, and that's why I
don't mention it.
Put images in content? Sure, I totally agree.
And making them match as
**.png -> content/{1}.png
will also eliminate another special purpose directory.
The only one that will remain is "raw", and it seems that there is a
real-life use case for it.
Mind me, I would still add a **.* matcher at the end of the
content-handling pipeline, so that content/** can still contain anything.
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, like for example a
raw document-dtd xml file.
So the content dir is about all content, that Forrest *may* alter.
The raw dir is about content that Forrest may *not* alter in any way.
I think we agree, no?
>>IIUC Someone said that images are not content but view.
>>Some images are, but other convey a message, and can be converted by
>>cocoon to be able to be viewed with a WAP phone for example.
>
> So 'content' images would go in content/images/, and 'view' images go in
> skins/<skin>/images/
Yup.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cleaning Forrest source directory madness
Posted by Jeff Turner <je...@apache.org>.
On Sat, Jun 14, 2003 at 04:48:01PM +0200, Nicola Ken Barozzi wrote:
>
> Jeff Turner wrote, On 14/06/2003 12.47:
> ...
> >Would it help if we make xdoc processing the default, and put
> >copied-across content in a special directory:
> >
> >content/index.xml
> >content/raw/foo.html
> >
> >Then if we then renamed 'content' to 'xdocs', and moved images/ into
> >there, we'd have the Maven structure:
> >
> >xdocs/*.xml
> >xdocs/images/*.png
> >xdocs/raw/foo.html
>
> I don't like the name "xdocs" for a dir, but that's really a minor issue.
I don't like it much either, so let me rewrite that as..
documentation/
content/*.xml
content/images/*.png
content/raw/foo.html
I don't know. I think we should do a 0.5 release with things as they are
currently, and then fix the problem properly in a future release. "fix
properly" meaning, get rid of special purpose directories altogether, and
let the user partition things however they want. Why try to _increase_
the amount of special directories in 0.5, when we really want to get rid
of them all in the future.
> I think I'm ok with this. More below.
>
> ...
> >How about:
> >
> > - Declaring images as 'content', and moving them under content/
> > - Keep resources for things that don't end up on the final site:
> >
> >resources/stylesheets
> >resources/conf # Sitemaps, etc
> >resources/lib
> >resources/classes
>
> Hmmm, now it's easy just to copy the resorces dir with the stylesheets
> and stuff, it would need some changes... but again, it makes sense.
>
> Ok, trying to recap and expand your proposal conceptually:
>
> documentation
> content -> model
> - files to process (1)
> - files not to process (2)
> resources -> controller
> skins -> view
That's a nice way to think of it.
...
> What can xdocs contain?
>
> - *.xml (documentdtd, faq, changes, todo, status, etc)
> - *.html (html4, to be tidied)
> - *.xhtml (xhtml1, xhtml2-dev)
> - *.wiki
> - *.png,gif,etc
(which makes 'xdocs' a rather bad name)
> Shall we negate the possibility of handling images in the xdocs dir? I
> think no. Also because this does not preclude someone from putting them
> in the /images/ dir and getting them from there. I'd do just that for
> Forrest BTW.
Sorry, I didn't follow. What /images/ directory? For images, all I
suggest is that they be reclassified as content:
content/images/*.png
> IIUC Someone said that images are not content but view.
> Some images are, but other convey a message, and can be converted by
> cocoon to be able to be viewed with a WAP phone for example.
So 'content' images would go in content/images/, and 'view' images go in
skins/<skin>/images/
...
--Jeff
Re: Cleaning Forrest source directory madness
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 14/06/2003 12.47:
...
> Would it help if we make xdoc processing the default, and put
> copied-across content in a special directory:
>
> content/index.xml
> content/raw/foo.html
>
> Then if we then renamed 'content' to 'xdocs', and moved images/ into
> there, we'd have the Maven structure:
>
> xdocs/*.xml
> xdocs/images/*.png
> xdocs/raw/foo.html
I don't like the name "xdocs" for a dir, but that's really a minor issue.
I think I'm ok with this. More below.
...
> How about:
>
> - Declaring images as 'content', and moving them under content/
> - Keep resources for things that don't end up on the final site:
>
> resources/stylesheets
> resources/conf # Sitemaps, etc
> resources/lib
> resources/classes
Hmmm, now it's easy just to copy the resorces dir with the stylesheets
and stuff, it would need some changes... but again, it makes sense.
Ok, trying to recap and expand your proposal conceptually:
documentation
content -> model
- files to process (1)
- files not to process (2)
resources -> controller
skins -> view
So if we decide that the user can control the position of (1) and (2) we
can have the Maven-like layout.
documentation
xdocs
raw
resources
stylesheets
conf
lib
classes
skins
skinname
images
stylesheets
What can xdocs contain?
- *.xml (documentdtd, faq, changes, todo, status, etc)
- *.html (html4, to be tidied)
- *.xhtml (xhtml1, xhtml2-dev)
- *.wiki
- *.png,gif,etc
Shall we negate the possibility of handling images in the xdocs dir? I
think no. Also because this does not preclude someone from putting them
in the /images/ dir and getting them from there. I'd do just that for
Forrest BTW.
IIUC Someone said that images are not content but view.
Some images are, but other convey a message, and can be converted by
cocoon to be able to be viewed with a WAP phone for example.
So, IIUC the last thing to decide is the default layout.
Should we do:
(1)
documentation
content
raw
xdocs
resources
skins
or
(2)
documentation
content
raw
resources
skins
or
(3)
documentation
xdocs
raw
resources
skins
(1) is the most similar to what we have now. It just creates the raw dir
inside content instead of itself.
(2) has no hierarchy but is inconsistent with the MVC screnario.
(3) is not conceptually clean, as it precludes us to have xdocs in a
/raw directory, and has inner nesting. But it's like the Maven layout,
so we could still decide to go for it for other reasons.
I'd say in turn (1)-(3)-(2).
What do especially *users* think?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cleaning Forrest source directory madness
Posted by Jeff Turner <je...@apache.org>.
On Thu, Jun 12, 2003 at 09:55:58AM +0200, Nicola Ken Barozzi wrote:
<snip resources explanation/>
...
> Now we have the the content/ dir can contain as-is content, and that
> html files to process have to be separated by different extensions.
>
> The problemn with the plain content/ dir is that the dir space of xdocs
> and content are not separate, and create a nesting that is not there
> conceptually.
>
> But the biggest problem is with the html files in xdocs, that are *not*
> processed. That means that the xdocs dir, that processes xml files, can
> contain html files that it does not process and ihtml files that it
> processes. And I still am not sure it's this way.
Why would anyone put *.html inside the xdocs/ directory? The *.ihtml and
*.ehtml files are there because they're XML.
> This was the result of two different dir management visions, the
> -separate filetypes in dirs- one and -keep all files in the same
> dirspace-. The problem is not that either approach is inherently flawed,
> but that they are both applied not consistently.
Why is the separate-directories model inconsistently applied?
Would it help if we make xdoc processing the default, and put
copied-across content in a special directory:
content/index.xml
content/raw/foo.html
Then if we then renamed 'content' to 'xdocs', and moved images/ into
there, we'd have the Maven structure:
xdocs/*.xml
xdocs/images/*.png
xdocs/raw/foo.html
Just picking up on one aspect here:
....
> resources all stuff that has to be referenced as-is
> mixed all "non-digestable" things "mixed"
> images images that have a global use in all pages
> -other-
....
> resources all stuff that has to be referenced as-is
....
> resources all stuff that has to be referenced as-is
> images images that have a global use in all pages
> -other-
How about:
- Declaring images as 'content', and moving them under content/
- Keep resources for things that don't end up on the final site:
resources/stylesheets
resources/conf # Sitemaps, etc
resources/lib
resources/classes
--Jeff