forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Cleaning Forrest source directory madness
Date Mon, 16 Jun 2003 10:02:31 GMT


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)
---------------------------------------------------------------------


Mime
View raw message