forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [RT] Directory structure and configuration
Date Wed, 11 May 2005 09:34:10 GMT
On Wed, 2005-05-11 at 09:07 +0200, Ferdinand Soethe wrote:
> > 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.
> >


+1

In the view "package" there are a lot configuration files needed. I
would like to see *one* single place for configuration.

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

-1

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

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

>   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

No that is not practical IMO because I can imaging that plugins would
sometimes need their own configuration. Having all in top level will
loose the overview.

Instead their should go to FORREST-INF. Like
FORREST-INF/
  org.apache.forrest.plugins.output.viewHelper.inx/
    default.fv
  forrest.xml
  ...


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

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

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

+1

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

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

Anyway I suggest (like Nicola) to place all this in resources/ because
after all they are resources. ;-) Like here would go as well templates/
(for the viewHelper project-specific contract implementations) like.

resources/
  templates/
    xhtml/
    inx/
    {format}/

> 
>   resources/
>     schema/
>     stylesheets/
> 
>   * the following changes are inspired by the other thread (on change
>     in terminology)
> 

see above.

>   static-output/ instead of build/site/  * say what it is

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.


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

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

-1 see 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.

> wdyt?
>                                            
> --

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message