forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "yachting heritage" <cont...@yachting-heritage.com>
Subject Re: Cleaning Forrest source directory madness
Date Mon, 16 Jun 2003 13:31:17 GMT
can you remove me from your mailing list
----- Original Message ----- 
From: "Nicola Ken Barozzi" <nicolaken@apache.org>
To: <forrest-dev@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)
> ---------------------------------------------------------------------
>
>



Mime
View raw message