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)
