You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Dev at weitling <de...@weitling.net> on 2006/09/13 23:52:30 UTC
Resent: Explanation of the Cocoon directory structure
Phhh... sorry, sent this eMail to the wrong mailing list first. Time to
go to bed...
Hi!
The Cocoon directory structure isn't very concise: many directories with
the same or at least similar names at different locations, some
directories with non-intuitive names (e.g. lib/endorsed: why endorsed?).
If there's a problem I don't know where to look, I don't know where to
place my files, I don't know which parts are superfluous and and and...
Are docs about that anywhere in the outside world without having to pay
> $ 30 for an outdated book?
Bye,
Florian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Resent: Explanation of the Cocoon directory structure
Posted by "Steven D. Majewski" <sd...@virginia.edu>.
On Sep 13, 2006, at 5:52 PM, Dev at weitling wrote:
> Phhh... sorry, sent this eMail to the wrong mailing list first.
> Time to go to bed...
>
> Hi!
>
> The Cocoon directory structure isn't very concise: many directories
> with the same or at least similar names at different locations,
> some directories with non-intuitive names (e.g. lib/endorsed: why
> endorsed?).
>
> If there's a problem I don't know where to look, I don't know where
> to place my files, I don't know which parts are superfluous and and
> and...
>
Things are more spread out in the cocoon source directories than they
are in the webapp.
( And if you're asking about lib/endorsed, then I think you're
probably looking at the source dirs. )
I think things are spread out because there are a lot of build and
configurations options.
Things are divided into core files and libraries and various optional
blocks, which get merged
together when you build the cocoon webapp.
Once you do a build, most of the stuff you'll actually want to look at
( at least until you get to the point of wanting to read some of the
java sources )
is in the samples directories. The examples there can also be
stripped out of a production
build, but they are great to have to look at when you're beginning.
You can, when starting out, just stick your own samples and tests in
a subdirectory of the samples
directory, as the sitemap does an automount of any directories below it:
<!-- ========================= Automount
============================= -->
<map:match pattern="*/**">
<map:mount check-reload="yes" src="{1}/" uri-prefix="{1}"/>
</map:match>
</map:pipeline>
But it's much better to keep the cocoon installation and your site
files separate.
If you look at the top level sitemap, you'll see a section about
redirecting to user
directories. If you want to use this feature, you should check that
the appropriate
option for your system is uncommented:
<!--+
| mount user directories
|
| The location of user directories depends heavily on the
operating
| system used. Uncomment the one below that suits your
environment.
|
| NOTE: you might want to comment out the entire section for a
| production environment.
+-->
<map:match pattern="~*/**">
<!-- unix -->
<map:mount check-reload="yes" src="/home/{1}/public_html/" uri-
prefix="~{1}"/>
<!-- macosx -->
<!--map:mount check-reload="yes" src="/Users/{1}/Sites/" uri-
prefix="~{1}"/-->
<!-- win32 -->
<!--map:mount check-reload="yes" src="/Documents and Settings/
{1}/My Documents/My Website/" uri-prefix="~{1}"/-->
</map:match>
Or, even better, further down in that file:
<!--+
| Find a match in the "mount-table.xml" file, if present. It
allows to mount other
| directories without touching this main sitemap (and thus
loosing changes on rebuild).
|
| Note that other mount-tables can be added here using the
xpatch ant task
| (see src/confpatch/mount-table.xmap)
+-->
<map:match pattern="../../mount-table.xml" type="mount-table">
<map:mount src="{src}" uri-prefix="{uri-prefix}"/>
</map:match>
That means you can keep the mount table as well as all your
application files outside of
the cocoon webapp directories, so that (among other things) you can
drop in a new cocoon
build without having to worry about relocating your files.
> Are docs about that anywhere in the outside world without having to
> pay > $ 30 for an outdated book?
>
There's a lot of stuff in the online docs. But it's not always where
you think to look for it, so try the
search bar at the top if you don't see what you want in the sidebar
index.
The problem is that cocoon is a big system with a lot of layers and a
lot of different ways to do things,
and it's not always clear what's the best approach. And none of the
available books actually
describe what I think is probably the current cocoon best practice.
So yes, they are kind of outdated,
and will probably only become more obsolete after 2.2 release, but
they all still have some useful info.
And since there's no perfect single source of info, you've got to
grab your clues where you can find
them. And even if you have to dig them out of the source code, the
source code will make more sense
after reading one or two of those books. ( All of the options about
where to put your files, for example,
are well covered in all of the books. )
And if you don't want to pay $30 ... well, if you look on Amazon you
can find used copies of those books.
In fact, the Ziegeler & Langham books seems to be out of print, so
you can ONLY get a used copy.
( "21 used & new available from $4.89" ! )
And a little searching brought up two free articles on Peachpit
press's web site:
Designing Cocoon Applications: http://www.peachpit.com/articles/
article.asp?p=30083&rl=1
A User's Look at the Cocoon Architecture: http://www.peachpit.com/
articles/article.asp?p=30037&rl=1
-- Steve Majewski / UVA Alderman Library.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Resent: Explanation of the Cocoon directory structure
Posted by Yves Zoundi <bi...@hermes.ulaval.ca>.
Hi,
the endorsed directory specifies that the libraries included in Cocoon
should be used instead of the libraries shipped with the jdk. For example
the Xalan version of the jdk is rather old compared to version shipped
with Apache Cocoon.
If you built Cocoon with examples, you can inspired yourself from that.
You add something to the sitemap.xmap (a configuration file)
<map:match pattern = "/location/path/index.html">
</map:match>
You create /location/path/index.html and you test it. The documentation is
pretty good online. You also have a wiki available and the community is
very active!
A java programming understanding is good for the questions you are asking
but not necessary for simple task.
You get try some examples, modify them and you will get more familiar with
Cocoon. Generally, you match a URL in the sitemap.xmap file, you create a
generator, you transform the content and you send the result to the
client's browser.
Feel free to ask more questions. Going through simple examples will get
you going.
-----Original Message-----
From: Dev at weitling <de...@weitling.net>
To: users at Cocoon <us...@cocoon.apache.org>
Date: Wed, 13 Sep 2006 23:52:30 +0200
Subject: Resent: Explanation of the Cocoon directory structure
> Phhh... sorry, sent this eMail to the wrong mailing list first. Time to
> go to bed...
>
> Hi!
>
> The Cocoon directory structure isn't very concise: many directories
> with
> the same or at least similar names at different locations, some
> directories with non-intuitive names (e.g. lib/endorsed: why
> endorsed?).
>
> If there's a problem I don't know where to look, I don't know where to
> place my files, I don't know which parts are superfluous and and and...
>
> Are docs about that anywhere in the outside world without having to pay
> > $ 30 for an outdated book?
>
> Bye,
> Florian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org