Hi Paulo Sérgio, Bertrand is right, cocoon documentation is a bit "abstract", examples add the pragmatic side of it :)
Anyway, for a longer introduction ... In the cocoon webapp folder you need the sitemap.xmap file. Then, if the sitemap is going to use other files, you'll need those files as well. After cocoon has been built, there is a default sitemap in the build/webapp/ folder. This sitemap declares some default matches which should not be deleted or altered (for example, those getting javascript resources for ajax), the default home page and the samples pages if you built cocoon with samples. Most important thing, it declares a default "mount sub-sitemaps", this means that if you ask http://localhost:8888/myapp/ it wil search for a myapp folder containing a sitemap.xmap file. So, the preferred way is to leave the default sitemap.xmap file in the webapp directory, and develop your cocoon app as a separate folder. This means that installing your cocoon application in a built cocoon is jsut a matter of copying your app folder inside the cocoon webapp folder. There is also a facility to ease developement, it's called "mount table". With mount table you can have cocoon read you application even if it's not a subfolder of the cocoon webapp. This is important because the cocoon webapp folder will be deleted if you rebuild cocoon completely, so it's always safer not to develop directly in that folder! When you package your cocoon app as a WAR, you will include your application folder as a subfolder of the cocoon webapp, remove the mount table, and everything will keep on working. The mount-table.xml file is located in the mail cocoon folder (not in build or build/webapp folder) and a typical mount-table files is as follows : <mount-table> <mount uri-prefix="myapp" src="file://c:/path/to/your/webapp/folder/wherever/it/is"/> </mount-table> Mount table does not get cleaned even if you do a complete cocoon rebuild, so it's the perfect way of doing developement. So, wether you decide for mount-table or for developing directly in the cocoon webapp, in both cases you will have a "myapp" folder (or call it as you like) where you develop your cocoon app. The only required file is the sitemap.xmap. For example, a simple hello world cocoon app could be : sitemap.xmap <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0";> <map:components> <!-- declare the components (generators, serializers etc..) you use in your application. usually you can simply copy and paste this section from the default cocoon sitemap (build/webapp/sitemap.xmap) and the remove the ones you haven't used once you have finished with your application </map:components> <map:pipelines> <map:pipeline> <map:match pattern="hello"> <map:generate src="hello.xml"/> <map:transform src="browser.xsl"/> <map:serialize type="xhtml"/> </map:match> </map:pipeline> </map:pipelines> </map:sitemap> hello.xml <page title="Hello"> <content> Hello world! </content> </page> browser.xsl <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> <xsl:template match="page"> <html> <head> <title><xsl:value-of select="@title"/></title> <head> <body> <xsl:apply-templates select="*"/> </body> </html> </xsl:template> <xsl:template match="content"> <xsl:apply-template select="*|node()" mode="content"/> </xsl:template> <xsl:template match="text()" mode="content"> <xsl:copy/> </xsl:template> </xsl:stylesheet> This is quite a complete example : generating a page starting from an XML and thru an XSLT. This is obviously overkill for a simple "Hello world!" page, but to understand the power of cocoon, think about a more complex XML : <page title="Complex hello"> <content> This is a more complex helo world page! </content> <related-links> <link href="http://www.helloworld.com";>The hello world site</link> <link href="http://www.anothersite.com";>Another site</link> </related-links> <sidebox> This is a sidebox for the page </sidebox> </page> And the related XSLT to render it on a browser : <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> <xsl:template match="page"> <html> <head> <title><xsl:value-of select="@title"/></title> <head> <body> <table> <tr> <td class="content" rowspan="2"> <xsl:apply-templates select="content"/> </td> <td class="sidebox"> <xsl:apply-templates select="sidebox"/> </td> </tr> <tr> <td class="related-links"> <xsl:apply-templates select="related-links"/> </td> </tr> </body> </html> </xsl:template> <xsl:template match="content"> <xsl:apply-template select="*|node()" mode="content"/> </xsl:template> <xsl:template match="sidebox"> <xsl:apply-template select="*|node()" mode="content"/> </xsl:template> <xsl:template match="related-links"> <ul> <xsl:for-each select="link"> <li> <a href="@href"><xsl:value-of select="."/></a> </li> </xsl:for-each> </ul> </xsl:template> <xsl:template match="text()" mode="content"> <xsl:copy/> </xsl:template> </xsl:stylesheet> And think about writing differents XSL to render the same page on a PDA (so, with a thin layout), in a printable HTML, in a PDF, in WML, or exposed as an XML webservice. The sitemap can be used to switch between different XSLTs depending on the url, the client user agent or whatever else. <map:pipeline> <map:match pattern="hello.html"> <map:generate src="hello.xml"/> <map:transform src="browser.xsl"/> <map:serialize type="xhtml"/> </map:match> <map:match pattern="hello.pdf"> <map:generate src="hello.xml"/> <map:transform src="pdf.xsl"/> <map:serialize type="pdf"/> </map:match> <map:match pattern="hello.print"> <map:generate src="hello.xml"/> <map:transform src="browser-printable.xsl"/> <map:serialize type="xhtml"/> </map:match> ... </map:pipeline> Also, you can easily serve an entire folder (we'll call it "documents") from the sitemap using regular expressions in your matchers : <map:pipeline> <map:match pattern="*.html"> <map:generate src="documents/{1}.xml"/> <map:transform src="browser.xsl"/> <map:serialize type="xhtml"/> </map:match> <map:match pattern="*.pdf"> <map:generate src="documents/{1}.xml"/> <map:transform src="pdf.xsl"/> <map:serialize type="pdf"/> </map:match> ... </map:pipeline> Then suppose the page was generated somehow aggregating database, static, webdav, ldap and from other webservices, as long as you keep on using the XML syntax you defined (in our case, "page" containing "content", "related-links" and "sidebox") you will be able to offer you super complex content to different platforms and in different formats in a modular, scalable, easily expandible way. Hope this helps, Simone Paulo Sérgio Medeiros wrote: > Hi all, > > as you see im begining with Cocoon and im trying to construct my first > app: "hello world". > The tutorials and documentation makes very clear the concepts like the > pipeline, transformers etc. > > But, one crucial thing that i haven't saw is what i need im my webapp > folder after Cocoon build. Im not refering to how i edit the > local.block.properties file (thats ok), but to the samples and lot of > files that comes in the folder after the build. > > Thanks, > Paulo Sergio. -- Simone Gianni --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
