Any idea what the performance difference might be? In looking further into this, I have discovered that the conventional parameter method, while complicating the sitemap, will lead to less complicated xslt code and processes in the other transformation files.
-----Original Message----- From: Willy Reinhardt [mailto:[EMAIL PROTECTED] Sent: Monday, December 27, 2004 12:08 PM To: users@cocoon.apache.org; [EMAIL PROTECTED] Subject: Rép. : URL extensions versus URL parameters for passing values to XSLT Hi, According my experience the pattern matching system provide best performances because cocoon caching can handle different document according url. With parameters it proceed whole document again. Happy new year to Cocooners ! Willy >>> [EMAIL PROTECTED] 27/12/04 16:15 >>> We are going to implement a web site feature that allows users to change text sizes by clicking a one of three buttons (small, medium/default or large) or changing to a "print friendly view" or default view by clicking a link in a breadcrumb. Each of these options passes values to the sitemap map which in turn uses the values to access the proper xslt and css resources. I can do this one of two ways. I can use the pattern matching which is the easiest, or parameters, which appears to be the conventional way to go. For pattern matching, here how I have things setup. For the default view, default text size will use the extension .html, the small text size can use the URL extension .htmlst and the large text size can use the extension .htmllt. So, webpage.html is default view default text size, webpage.htmlst is default view small text size and webpage.htmllt is default view large text size. For the print friendly view, default text size will use the extension .htmlpv, the small text size can use the URL extension .htmlstpv and the large text size can use the extension .htmlltpv. The following sitemap snippet shows how easy it is to use pattern matching with the extensions to provide information to the xslt processor: <map:match pattern="*-*.*"> <map:generate src="/content/xxx-{2}.html"/> <map:transform src="/xslt/page2html.xsl"> <map:parameter name="cssFileTemp" value="output-{3}.css"/> <map:parameter name="siteTypeTemp" value="{3}"/> </map:transform> <map:serialize type="html"/> </map:match> where cssFileType is passed to an xslt html template to build a link to a css file and siteTypeTemp is used in the xslt for a number of purposes. The css files all build off the default css file, that which is used for the .html extension. For parameter matching, here how I have things setup. The parameter is vp, for view parameter. For the default view, default text size will use the extension .html, the small text size can use the URL extension .html?vp=st and the large text size can use the extension .html?vp=ltpv. So, webpage.html is default view default text size, webpage.html?vp=st is default view small text size and webpage.html?vp=lt is default view large text size. For the print friendly view, default text size will use the extension .html?vp=pv, the small text size can use the URL extension .html?vp=stpv and the large text size can use the extension .html?vp=ltpv. I'm not providing the sitemap snippet here, since it is a more complicated and contains more code. In this case there are a number of parameter tests that need to be run to get the correct text size and view values to pass to the xslt. So, what I'm trying to gather, is there a best practice for this in Cocoon. The extension method demonstrates the ease and capabilities of the Cocoon sitemap, but the parameter method is convention. What would others recommend? Gary T. Schultz Web Technical Administrator / GIS Coordinator Wisconsin Department of Commerce 6th Floor P.O. Box 7970 Madison, WI 1-608-266-1283 --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]