forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <samm...@soethe.net>
Subject Re: [RT] Directory structure and configuration
Date Wed, 11 May 2005 07:07:47 GMT

> Can you remind us what the thread was about, preferably by summarising
> the outstanding issues, or if that is too much work by providing a link
> to the archives.

This is the original thread:

http://marc.theaimsgroup.com/?t=110172152700001&r=1&w=2


with this being the original idea

> Currently we have (C = configuration) :
>
>   my-project/
>      status.xml
>      forrest.properties (C)
>      src/
>        documentation/
>          skinconf.xml   (C)
>          content/
>            xdocs/
>              site.xml   (C)
>              tabs.xml   (C)
>            classes/
>              CatalogManager.properties (C)
>            resources/
>              images/
>                **.gif||jpg||...
>
>
> Assumptions on how it should change:
>
> 1 - shallower dir structure
> 2 - single dir for configuration
> 3 - single dir for content
> 4 - content dir contains only content, not configuration
> 5 - no Forrest content outside of the conf and content dirs
>
>   my-project/
>          documentation/
>            conf/
>                 forrest.properties
>                 skinconf.xml
>                 site.xml
>                 tabs.xml
>            content/
>                 status.xml
>                 ** all other content
>
> Notes:
>
> a - the /documentation dir can be anywhere: when Forrest first starts
>      it shall search for some predefined directories, and then in the
>      whole directory structure till it finds forrest.properties.
>      Then it caches it in the user dir and uses that to resolve all
>      other directories.
>
> b - status.xml will become like all other files, and will not be
>      anymore in a fixed position, as it will match on DTD-
>
> Now here is a different layout (we may as well decide a mix between this
> and the previous one):
>
>   my-project/
>          forrest.xml
>
>          documentation/
>               status.xml
>               ** all other content
>
>               FORREST-INF/
>                 skinconf.xml
>                 site.xml
>                 tabs.xml
>
> Notes:
>
> c - forrest.properties is renamed forrest.xml and uses xml; this
>      ensures that the paths do not contain whitespace at the end.
>      Furthermore having forrest in the base dir is a clear sign
>      the the documentation of the project is done with Forrest, and
>      that it's to be launched in that dir.
>      This file must only contain the link to the *main* Forrest dir
>      and the output dir.
>
> d - The configuration is kept inside the documentation dir under
>      FORREST-INF/, in a similar way to WEB-INF. This shortens the
>      path to the documentation.
>
> This configuration has the advantage that the whole documentation is in
> one directory, and can be used also without forrest.xml.
> Let me enhance the discussion by talking about configuration.
>
>                      - O -
>
> We now have configuration in many different places, and I want to see it
> reduced.
>
> Furthermore, there have been requests to make our sitewide configuration
> more pinpointed to single dirs or files (special headers), and
> documentation set joins (multiproject docs).

with this being a possible outcome after considering the comments

>   my-project/
>          forrest.xml
>
>          content/
>               status.xml
>               ** all other content
>
>               FORREST-INF/
>                 skinconf.xml
>                 site.xml
>                 tabs.xml

In fact having re-read all of this I'd go another step and suggest
something like this (* = my reasons for this).

my-project/
  forrest.properties to become forrest-properties.xml
                     *you know what is is right away

  all other config files
                     *why not keep them in the root
                      much easier to find. no clutter to be expected
                      because there are not so many

  CatalogManager.properties
                     *why have a subdir just for one file?
                     
  content/
    status.xml
    site.xml
    tabs.xml
    former content of xdocs here and in subdirs if required

  content-untranslated/
    images, binaries ...

  * 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.

    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.
    


  resources/
    schema/
    stylesheets/

  * the following changes are inspired by the other thread (on change
    in terminology)

  static-output/ instead of build/site/  * say what it is
  server-space/  instead of build/       * to mark it as server workspace
    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?

wdyt?
                                           
--
Ferdinand Soethe


Mime
View raw message