Is there any example of how to organize an application into a block? - I don't know if I have to put some stuff in the blocks directory and other in the webapp directory - I don't know where to put the patches so that they are applied automatically by xpatch - I don't know how to mount the application into a top-level URI, not under 'samples'.
Thanks -----Original Message----- From: Simone Gianni [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 1:08 PM To: [email protected] Subject: Re: Organizing own project in cocoon? Hi Fernando, IMMO organizing your project as a block is a good way of doing it if you need extreme control on the cocoon environment, but for the 90% of cocoon projects it's not needed. You can simply create your directly structure composed by a folder (we usually have src/webapp) containing a sitemap.xmap and all the other stuff you need. Usually we have a src/webapp/resource folder, containing other folders like img, javascript etc.. for all the client side stuff. Then we usually create a stylesheets folder containing common xsls. Other application folders depend on the size and destination of your application, for example for an ecommerce site i would create folders like cart, catalogue, payment etc... all containing the needed files (forms, etc..) eventually creating other subfolders if needed. Then we usually have a src/main/ source folder containing java sources (and eventually a src/test folder containing junit tests). We also quite commonly use a lib/runtime and lib/compile folders, in lib/runtime we place jars needed by our application and not already included in cocoon, while in lib/compile we copy from cocoon the cocoon jars needed to have eclipse compile our java sources (if we develop custom cocoon components in that application). The build process if quite simple (can do with 20/30 lines of code), common operations are : - Compile you java classes, pack them in a jar, and place them in the target {$cocoon-webapp}/WEB-INF/lib - Copy lib/runtime/*.jar to {$cocoon-webapp}/WEB-INF/lib. - Copy your src/webapp into {$cocoon-webapp}/yoursitename - Eventually patch (XPatch) various cocoon configuration files to install your custom classes, if you need this Common xpatches are : - Patches to web.xml to install custom filters, servlets, or to change default cocoon parameters (quite common is the upload on disk and max upload size) - Patches to cocoon.xconf to configure and install your own cocoon forms (or other block's) components. - Patches to the root sitemap.xmap to add global matches (quite common, redirecting "" to "/yoursitename/") While developing, is quite handy to use the mount-table.xml instead of copying your src/webapp folder to cocoon. This file defines that /yourappname points to, say, "c:\Programs\Eclipse\workspace\siteproject\src\webapp\". This way you can change your application files (forms, xsl etc..) directly inside your ide, and see them change immediately, using the build only when you change java sources, and thus speeding the developement process a lot. In some projects, we also add an optional target in the ant build that would download the required cocoon version, unpack it, copy in the cocoon folder the local.build.properties and local.blocks.properties with trimmed versions made up for your application, and then launch the cocoon build. I don't like this very much, but can save your customer a lot of time in redeploy/manteinance and avoid to have them call you back after one month asking which version of cocoon they need or why they are having those ClassNotFoundExceptions (missing a block). Organizing a block would automagically solve a lot of this problems (since all the build is done by the cocoon build, including xpatches, copying of webapp files, carrying needed jars etc.., you just have to organize files in a certain way and copy them in the cocoon folder), but IMMO is a bit overkill for simple cocoon based applications. Simone -- Simone Gianni --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
