Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Wed, 11 May 2005 15:35:31 +0200
From: Ferdinand Soethe <sammler@soethe.net>
Message-ID: <1819180359.20050511153531@soethe.net>
To: dev@forrest.apache.org
Subject: Re: [RT] Directory structure and configuration
In-Reply-To: <1115804050.5082.37.camel@localhost.localdomain>
References: <coeqtf$usj$1@sea.gmane.org>
  <451249489.20050510232337@soethe.net>
 <42812E56.9030505@apache.org>  <111608415.20050511005448@soethe.net>
 <177618817.20050511090747@soethe.net>
 <1115804050.5082.37.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> forrest.properties to become forrest-properties.xml
> -1

> forrest.properties should become forrest.xml like Nicola suggested
> because it is the main configuration file for forrest like maven.xml for
> maven. ;-)

I can't see this as such a good reason to do it the same.

In my view:

If more filename speak for themselves, less people need to to
read documentation to get started and we'll have less questions to
answer in the list.

So unless there are technical reasons against it, why not be clear in
naming?

And sorry, 'forrest.xml' tells me nothing about the role if this file
other than it being an xml-file. The knowledge that it is the main
configuration file might be concluded by people who know the other
products, but then why limit easy understanding to such a small group.

Isn't it a bit like speaking latin in church because it is the language
spoken in all other churches ....

> ...and it has to go to FORREST-INF/!!!

OK, I can see why (see belowI and agree to a separate config directory now.
So how about calling it 'configuration'.
Plugin would then have their named config subdir in there.


>> 
>>   CatalogManager.properties
>>                      *why have a subdir just for one file?
>>    

> Yes should go as well into the FORREST-INF/.

OK, everybody +1 on having it in the conf dir (whatever we name it)

>>                   
>>   content/
>>     status.xml
>>     site.xml
>>     tabs.xml
>>     former content of xdocs here and in subdirs if required
>> 

> +1
this seem consensus as far as I can tell

>>   content-untranslated/
>>     images, binaries ...
>> 

> For me (like for Nicola) that are resources/ and would have to go to that dir.

>> 
>>   * I'd rather not have untranslated content in the resources tree
>>     as Nicola proposed (though I understand the logic behind it)
>>     because it is much harder to create references to files if their
>>     structure of  subdirs does not start from the same level as the
>>     subdirs in content.
>> 

> I do not understand. In the end everything should get resolved by
> cocoon:/(/) calls that means that problem would be the one of the
> controller. The reference you are talking about could e.g. be a simple
> site:images/xyz.png.

Let me explain from a use case where people have several content dir
called 'project1', 'project2' ... each one of the coming with their
own set of images each one being eventuelly replaces by project 5,6,7
when they are outdated.

To keep management simple I'd suggest to keep the images in a sub dir
structure equal to the docs structure to be able to easily delete a
project _and_ all ite resources.

Now this might still work with one layer of projects, but as soon as
you start having project1 with subproj11 and subproj12 people will
start having problem maintaining these separate trees.

So you can avaid a lot of maintenance errors when you simply put the
in the same directory. If not, at least keep the structure symetrical
as non-techniscal users will have an easier time making the
connection.

>>     In fact from a users perspective I'd even suggest to have raw
>>     content in the content dir for easier management, but I'm not sure
>>     that is possible.

> Hmm, then we need to discuss the placing of forrest:views into the
> content dir or in a dir for it own and creating a shadow content
> structure. There are some drawback to it like Ross stated the other
> day. 

I need to re-read Ross' comments, but again in my experience
maintenance will get harder the further the files that work together
are placed.


> I think we should keep build/ as top-level because that is most common
> in cocoon related projects. Everything that you now describe is part of
> some kind of build.

I will make this point one last time and then keep quiet about it.
This whole discussion was started because I wanted Forrest to become
more transparent for new people beyond the sworn in community. And
this goal is sometimes incompatible with making 'cocoonies' feel right
at home.

But we/you need to make up our mind about that. And if you decide to
stick to the technical naming we have now, we won't be able to explain
structure to normal people (or train it) and so I'd start working on a
gui interface that hides all this.


> ...but yeah static-output/ instead of site/, why not? ;-)

>>   server-space/  instead of build/       * to mark it as server workspace

> -1 see above
Same decision as above.

>>     tmp/         instead of build/tmp/   * if this is really server
>>                                            only otherwise move it up
>>                                            one level
>>     webapp/      instead of build/webapp/
>>                                          * perhaps we can do without
>>                                            this and move the files one
>>                                            up?
>> 

> I would rather keep webapp/ because it is closer to cocoon's webapp.
I could live with that because users have very little contact with
this area.


--
Ferdinand Soethe