You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ferdinand Soethe <sa...@soethe.net> on 2005/05/10 23:23:37 UTC
Re: [RT] Directory structure and configuration
What happened to the outcome of this thread? Will 0.7 have the change
in directory structure, is it postponed till 0.8 or did it die
somewhere along the road?
I'd be very interested to reduce the path to xdocs and remove the
one level layer difference between xdocs and content soon.
What can I do to make this happend? Assuming that it is not enough to
change the defaults for freshsite?!
--
Ferdinand Soethe
Re: [RT] Directory structure and configuration
Posted by Ferdinand Soethe <sa...@soethe.net>.
David Crossley wrote:
> So if someone can change the build system so that this file
> gets picked up by Java from a different location, then fine.
Yeah, I saw that. But I understood Nicola saying someplace else hat
could be done? Can it? Who knows what is needed?
--
Ferdinand Soethe
Re: [RT] Directory structure and configuration
Posted by David Crossley <cr...@apache.org>.
Ferdinand Soethe wrote:
>
> 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?
See the comment earlier in the thread, copied here:
>The CatalogManager.properties file needs to be
>available on the classpath when Cocoon starts.
>Can we move it to the new conf directory and
>have the classpath point to that location?
So if someone can change the build system so that this file
gets picked up by Java from a different location, then fine.
--David
Re: [RT] Directory structure and configuration
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ferdinand Soethe wrote:
>
>>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.
Correct. But the point is: when do filenames speak for themselves?
My experience has showed me that a name you're accustomed to is more
understandable than a long descriptive filename.
IOW:
/src
/build
is more understandable than
/source-files
/results-of-build-operation
...
> 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 ....
If a user cannot understand what forrest.xml is and edit it, he will not
be particularly helped in having it with a different name.
To make it easier to use, much more than just naming is needed (like a
GUI), and for developers, short and well-known names are better.
>>...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'.
Servlets have 'WEB-INF'. Linux has 'conf'. Speak the developer's
language. I had your same opinion a couple of years ago, and tried it,
but it did not work.
> 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.
I'm not sure I fully understand. Could you please post two example trees
for the two scenarios?
>>> 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.
Why? It's progressing nicely and things are being ironed out. Please
continue :-)
> 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.
Hmmm... wait a sec, read on:
>>...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.
Good point. We should only think about naming in the places that users
are forced to look at, and have a GUI to handle the rest (the config).
That is:
- forrest.xml (identify the project as containing forrest content)
- source directories (I find this very important, see above my request
for an example)
Cool stuff, this is moving! :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Directory structure and configuration
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Juan Jose Pablos wrote:
>
>
>>It was setup like that so you do not need to copy images accross. I
>>think that it was used just for the skin. If we move already the skin
>>out (under /skin) then we should put them within the content directory
>>as they are conten as well.
>
>
> OK so unless anybody objects, we'll do away with a separate folder
> for images and have them along the transformed content.
I'm -1 for this *before* the 0.7 release, but +0 for it after the 0.7
release.
Ross
Re: [RT] Directory structure and configuration
Posted by Ferdinand Soethe <sa...@soethe.net>.
Juan Jose Pablos wrote:
> It was setup like that so you do not need to copy images accross. I
> think that it was used just for the skin. If we move already the skin
> out (under /skin) then we should put them within the content directory
> as they are conten as well.
OK so unless anybody objects, we'll do away with a separate folder
for images and have them along the transformed content.
I will be away till Tuesday, after that I'll try to summarize the
current state of our discussion.
--
Ferdinand Soethe
Re: [RT] Directory structure and configuration
Posted by Juan Jose Pablos <ch...@apache.org>.
Ferdinand Soethe wrote:
>
> Why are images different than raw content and need to go in a separate
> dir. Or is this merely a recommended option to place an image?
It was setup like that so you do not need to copy images accross. I
think that it was used just for the skin. If we move already the skin
out (under /skin) then we should put them within the content directory
as they are conten as well.
Could I
> have images in the content directories just as well?
>
I think so...
Re: [RT] Directory structure and configuration
Posted by Ferdinand Soethe <sa...@soethe.net>.
I'll carry this question from the 'Clean up freshsite to be just
that'-thread into this discussion:
According to Ross in 0.7 all raw content (not to be transformed by
forrest) is to be placed alongside xml-content in the same directory
that we might call 'content' in the future.
What he could not answer is my question why we are having the debate
about images in the resources-branch here.
Why are images different than raw content and need to go in a separate
dir. Or is this merely a recommended option to place an image? Could I
have images in the content directories just as well?
Thanks for your help,
--
Ferdinand Soethe
Re: Who uses Forrest? (was Re: [RT] Directory structure and configuration)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Ross wrote
>
>
>>>I will make this point one last time and then keep quiet about it.
>>
>>I'd rather you didn't keep quiet. Your opinion is critical in this.
>
>
> OK, since you asked for it :-)
>
> 1. End users
>
...
> So why not make it easier for these people (and win broader support) as
> long as it doesn't mean making compromises on quality.
I'm all for making it easier, but I disagree with *how* it is made
easier. I would prefer it if an end-user could pick up forrest and build
a simple, standard site *without* looking at *any* docs other than a 3
line install and run description.
To achieve this we need helper tools, not different documentation (of
course, it is not as clearly separated as this, *some* documentation
will always be needed for the end-user).
> 2. Technical users
>
> I question the fact that Forrest is currently easy
> to understand for technical users. I think it is only easy to
> understand for people with a cocoon background!
Without an understanding of Cocoon pipelines, generators, transformers,
serialisers, matchers, etc. etc. they won't get very far in Forrest. It
is possible to do some skin customisation without Cocoon knowledge, but
you can't do anything else. If you can find a way around this then that
is great.
Sure, (non-technical) end-users have been empowered by the plugins, but
why bother explaining to them how to configure forrest.properties, or
forrest.xml or forrest.conf.xml or whatever we name it. Wouldn't it be
better to have a script or gui that said "this plugin does XYZ, do you
wnat to use it?" Then they don't care what the file is called.
> 3. GUI
...
> However I would really like working towards making Forrest a system
> where non-technical power users have a chance to throw away their
> gui-crutches at some point and work with the whole flexibility of
> Forrest below.
This blurs the distinction between non-technical end-users and technical
users. What is a "power" user? How do we define one? What will they be
doing with Forrest?
If they simply want to configure the way Forrest works by employing
verious plugins and perhaps configuring their skin then a set of
scripts/guis are what are need, coupled with clear documentation about
the skinning system.
If they want to make Forrest do something that it can't already do they
will have to learn about the Cocoon way of doing things because Forrest
is a Cocoon app. That makes them a technical user - or at least someone
willing to become a technical user. They will then need to read Cocoon
docs as well as our own.
---
I am still +1 on anything that makes it easier for end-users. This
includes, but is not limited to, renaming build targets to enable
clearer docs to be written, or (preferably) building helper scripts that
remove the need for the end-user to know the target names. These scipts
can then be written from the perspective of an end user and the
underlying framework can stick with the terminology used by the devs.
Furthermore these scripts can be used in the Eclipse plugin (which,
incidentally, already has a basic wizard for creating a new site).
I'm still -1 on changing the names of the configu files etc. we need to
stay close to the nearest thing we have to "standards", that is we need
to see the underlying structure of Forrest continuing to look like a
Cocoon application. I pick on "a Cocoon appication" as our standard
because that is what Forrest is, and very often we find ourselves
referring technical users to Cocoon docs. It would therefore make sense
for files to be named the same and located in the same locations as
documented in those docs.
> P.S.
>
> All this does not mean that all the changes I suggested serve that
> goal. That I'm happy to discuss and question any time.
Yes, I'll return to those threads when we are agreed on who we are
targetting and what our aims in the resturcuting is.
Ross
Re: Who uses Forrest? (was Re: [RT] Directory structure and configuration)
Posted by Ferdinand Soethe <sa...@soethe.net>.
Ross wrote
>> I will make this point one last time and then keep quiet about it.
>
> I'd rather you didn't keep quiet. Your opinion is critical in this.
OK, since you asked for it :-)
1. End users
I agree that there are limits in what we can do to make
end users understand Forrest.
Pls. note however that Forrest is close enough to a system that can
be used out of the box and it will attract end users. And searching
the German web for Forrest sites I found a number of sites that were
certainly not build by Cocoonies.
So why not make it easier for these people (and win broader support) as
long as it doesn't mean making compromises on quality.
2. Technical users
I question the fact that Forrest is currently easy
to understand for technical users. I think it is only easy to
understand for people with a cocoon background!
But I'm convinced that the majority of people that could/will use
Forrest in the future will NOT have that background. In fact many
won't even have the unix/linux or java/web applications-background
that helps understand many terms.
3. GUI
You know that I like to have a GUI for Forrest because I would make it
much easier to convince people in the beginning.
However I would really like working towards making Forrest a system
where non-technical power users have a chance to throw away their
gui-crutches at some point and work with the whole flexibility of
Forrest below.
Which is a good reason to have a GUI AND make the system easier to
understand,
don't you think.
Ferdinand
P.S.
All this does not mean that all the changes I suggested serve that
goal. That I'm happy to discuss and question any time.
Who uses Forrest? (was Re: [RT] Directory structure and configuration)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
>>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.
I'd rather you didn't keep quiet. Your opinion is critical in this.
> 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.
Who currently uses Forrest?
Who will Forrest be used by in the future?
and most importantly:
Who is Forrest aimed at?
I ask these questions because what Ferdinand is proposing relies on us
being able to answer these questions. He is proposing considerable
changes in the names of important files, directory structures and
concepts in order to make Forrest more understandable for a, as yet,
unidentified, end user.
Right now, in my view, Forrest does not want to attract end users that
are not comfortable with XML, CSS, XSLT and Cocoon Pipelines. In my view
we should be improving our docs from a *technical* perspective rather
than a *user* perspective. We should be making it really easy for people
to build new plugins and skins. We should be making it really easy for
technical users to come along and enhance the Forrest application.
Changing our terminology to one that is not appropriate for technical
users, most likely coming from a Cocoon background or from an XML/XSLT
background, may have actually make it *harder* for the very users we are
trying to attract (IMHO).
I do understand what Ferdinand is trying to do, and I agree that making
Forrest more accessible to non-technical end users is very important.
However, I'm not convinced the approach is correct.
I would prefer to see (non-technical) end users supported by a set of
tools for configuring Forrest, preferably with a GUI interface, but at
the very least by ant scripts that will ask the user questions and
configure the system accordingly.
For example, doing 'forrest seed' should ask what the site name is, what
skin should be used, what plugins will be required and so on. The end
result will be a seed site that doesn't need customising through the
editing of config files and so the (non-technical) user doesn't need to
know anything about them. Consequently we can keep their locations and
names familiar to the technical user.
I'm +1 on name changes that make it easier to document (non-technical)
end-user interfaces to the application. But I'm -1 on changing things
that the (non-technical) user should have no need to see. I'd rather see
the effort go into writing helper applications/scripts that hide the
complexities of Forrest from such users whilst still keeping the
underlying design familiar to out technical users.
Writing Ant scripts is surprisingly easy once there are a set of
examples to follow. Perhaps effort should be put into user focused
scripts rather than complex name changes that will resonate through all
our existing code and documentation.
Ross
Re: [RT] Directory structure and configuration
Posted by Ferdinand Soethe <sa...@soethe.net>.
> 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
Re: [RT] Directory structure and configuration
Posted by Thorsten Scherler <th...@apache.org>.
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)
Re: [RT] Directory structure and configuration
Posted by Ferdinand Soethe <sa...@soethe.net>.
> 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
Re: [RT] Directory structure and configuration
Posted by Ferdinand Soethe <sa...@soethe.net>.
Ross Gardler wrote:
RG> Can you remind us what the thread was about, preferably by summarising
RG> the outstanding issues, or if that is too much work by providing a link
RG> to the archives.
I'll try to dig it up the next days (I always read this in my local
archive) since I'm not sure what the final decision on it was.
--
Ferdinand Soethe
Re: [RT] Directory structure and configuration
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> What happened to the outcome of this thread? Will 0.7 have the change
> in directory structure, is it postponed till 0.8 or did it die
> somewhere along the road?
>
> I'd be very interested to reduce the path to xdocs and remove the
> one level layer difference between xdocs and content soon.
>
> What can I do to make this happend? Assuming that it is not enough to
> change the defaults for freshsite?!
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.
Ross
Re: [RT] Directory structure and configuration
Posted by Juan Jose Pablos <ch...@apache.org>.
Ferdinand Soethe wrote:
> What happened to the outcome of this thread? Will 0.7 have the change
> in directory structure, is it postponed till 0.8 or did it die
> somewhere along the road?
>
> I'd be very interested to reduce the path to xdocs and remove the
> one level layer difference between xdocs and content soon.
>
> What can I do to make this happend? Assuming that it is not enough to
> change the defaults for freshsite?!
I think that we should move src/documentation/content/xdocs -->
src/documentation/content
Then added a test on a "forrest upgrade" target that test for
${project.content-dir}/site.xml
if fail then display information about why we are making this change and
how to resolve this issue.
WDT?
Cheers,
Cheche