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 Sun, 15 Jun 2003 15:54:57 GMT

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


Mime
View raw message