On Sun, 10 Feb 2002, Donald Ball wrote: > i've been thinking recently on what it's like to get starting with c2, and > what one has to do to build a new webapp using c2. i just scanned the bulk > of the c2 user docs and note that there's nothing that tells you how to > get started building your own webapp using c2. it's easy and > well-documented how one installs the c2 sample webapp, but that's only > half of the story, and maybe not even the best starting point for a new > webapp. i guess the idea is that users are supposed to take the sample c2 > webapp, rip out the sample stuff and modify it for their own purposes. > and at least one useful option, precompiling the sitemap and xsp pages, is > only easily available to users if they choose that approach and continue > to use c2's build file and directory structure in their webapp.
I've posted recently how we setup a C2 dev infractructure. The main points to controll are: cocoon.xconf sitemap.xmap logkit.xconf web.xml WEB-INF/lib WEB-INF/classes For cocoon.xconf it would be convenient to have a similarity as with the user-roles attribute to define ones own cocoon.xconf extension so you don't have to edit the original cocoon.xconf everytime you deploy a newer Cocoon dist (this needs to setup dummy user-roles and user-xconfs included in the original cocoon.xconf file). We rename the sitemap.xmap to something different and install our own sitemap.xmap which is a root for all our apps (which gets mounted as sub-sitemaps). You can mount the original sitemap by a match-all rule at the end of the custom root-sitemap to have access to the samples in a dev environment. The logkit.xconf is usually twiddled to get rid of the annoying free memory announcement of the store.janitore every 10 seconds. The web.xml needs to be modified in case you use different jdbc drivers or specifics for your servlet engine (classloader). WEB-INF/lib and WEB-INF/classes is used to install own jar/classes. Finally all of our own apps have an deploy ant target to copy the sub-sitemaps and the necessary xml/xsl/xsp etc. files into the right place as well as the custom jars/classes for testing. At the end you have to do the following steps to upgrade to a newer Cocoon version (well changes introduces from Cocoon version to the next version will still have to be reflected in the custom config files) 1. remove the old cocoon servlet context 2. expand the new cocoon.war file into that context 3. redeploy your Cocoon customizations into that context. This will rename the original sitemap.xmap and copies (or overwrites) others to fit into the environments like describbed above 4. redeploy your Cocoon webapps into that context Step 3 is done in our env with a special module having it's own ant build.xml. Step 4 is common to all our Cocoon apps we develop. This approach can also be used to setup production environment where we have a special production user which has CVS access to our repos and does the steps above in a production environment (maybe with special deployment ant targets for that environment). > but like i said, that might not be the best approach for new users. for > one thing, the configuration files and sample content are very thorough > and complex - not necessarily the best starting point for a new webapp. I totally agreed here. That's why we have a special root sitemap which only contains mounts to sub sitemaps (and the original sitemap is also mounted here) > the c2 build file is not only responsible for building the c2 sample > webapp, but also for building the c2 library and documentation, neither of > which are necessary or even useful for c2 users. Not sure here. I regularly use the online documentation that comes with Cocoon as reference and thus use the mounting mechanism to have it at hand) > also, the c2 repository > isn't frozen, it changes. but the user has to fork from the repository > when they start to build their webapp, and then has to manually keep their > cocoon configuration files in sync with the distro. that's a hassle. For some configuration files you have to at the moment (cocoon.xconf, web.xml). For other you don't have to if you follow the approach above. > so i was thinking that a (partial) solution would be to make available, > and maintain, a c2-skeleton distro, with a minimal directory tree and > configuration files, no sample content, a build file that just builds the > webapp and can precompile things. sort of a best practices c2 skeleton for > others to use. something like: > > /WEB-INF > /etc > sitemap.xmap > cocoon.xconf > logkit.xconf > /lib > cocoon2.jar > ... > web.xml > build.xml In fact this doesn't free you from updating you configfiles when changes had occurrend in the CVS. our approach seems to minimize that to the absolute minimum (with the exception of cocoon.xconf, which doesn't have a user extension as well as the web.xml file) > (i suggest hiding the cocoon configuration files under WEB-INF so that > they'll be more protected in case of a malfunction. there can be passwords > and such in cocoon.xconf, at the very least.) That's ok for cocoon.xconf (as there is usually only one) but not sure about sitemap.xmap (think of sub-sitemaps). If you attemp to use a root sitemap that has only mounts to subsitemaps, than yes, hiding it could advance security. > i know this is a pretty boring and simple suggestion, but based on my > experiences watching and reading about people trying to get started with > c2, i think it could help a good bit. i mean, now you, you download the c2 > binary distribution, unpack it, and don't have any roadmap for going > anywhere after installing the sample webapp. providing a c2 webapp > skeleton would start to fill that void. I'm interested in your oppinion about the approach I've mentioned above (which I like better than the one with a sole skeleton webapp target). Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
