cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: A Cocoon2 Menu / Navigation System
Date Fri, 11 May 2001 14:28:43 GMT
On Thu, 10 May 2001, Ulrich Mayring wrote:

> Heh, I remember when I first asked about application design with Cocoon1
> and a common XSP taglib framework, some people said they're not
> interested, because they're waiting for Cocoon2 and the Sitemap. I
> didn't understand then and I don't understand now how the Sitemap can
> solve this problem, because it's a proprietary thing designed to solve
> one specific problem. We need a general tool, my suggestion was to
> convert the Sitemap over from its proprietary format into a regular XSP
> taglib and make it extensible. I don't know enough about Cocoon2 to
> decide whether this can be done at all, but Cocoon2 IMHO turns out to be
> a mess of proprietary "maps".
>
> A Cocoon1 app is portable, because the XML pages are pretty much
> self-contained - a Cocoon2 app is a different beast, it has its logic
> not only inside the XML pages themselves, but spreads it out over all
> those map files. Converting a servlet to a Cocoon1 app is pretty
> straightforward, as is the way back. Cocoon2 is more of a "take me 100%
> or leave me" deal.

that's inane. if you do anything complex with c1 (e.g. anything other than
a single xslt transformation), it's not portable without some work. you
have the same situation in c2, it's just that in c2, all of the
cocoon-specific stuff is put in one sitemap file instead of being put in
cocoon-specific processing instructions in lots of files. if you don't
know enough about c2 to say if something's feasible, you oughtn't slam it.
take a look, i think you'll be pleasantly surprised.

fwiw, my sitemap consists of essentially two matches:

   <map:match pattern="*">
    <map:aggregate element="root">
     <map:part src="plain/meta"/>
     <map:part src="plain/{1}"/>
    </map:aggregate>
    <map:act type="resource-exists">
     <parameter name="url" value="context://style/{1}.xsl"/>
     <map:transform src="style/{../1}.xsl"/>
    </map:act>
    <map:select>
     <map:when test="wap">
      <map:transform src="style/wziml-wml.xsl"/>
      <mal:serialize type="wap"/>
     </map:when>
     <map:otherwise>
      <map:transform src="style/wziml-html.xsl"/>
      <map:serialize type="html"/>
     </map:otherwise>
    </map:select>
   </map:match>

   <map:match pattern="plain/*">
    <map:generate src="content/{1}.xml" type="serverpages"/>
    <map:serialize/>
   </map:match>

i can step through the flow if you need translation, but i find this is a
hell of a lot saner than messing with a bunch of PIs.

> It'll be interesting to observe how easy it will be to maintain a larger
> Cocoon2 app. Imagine something in the Sitemap behavior changes with a
> new version - you may have to test each and every possible request to
> your app to find out if you can upgrade. It's hard enough upgrading
> Cocoon1, even though at this point there are only relatively minor
> changes, since most work focuses on Cocoon2.

uh, no. after we do a final release, sitemap behavior changes will not
occur without a change to the namespace uri, and we can easily have
multiple stylesheets to operate on different versions of the sitemap
namespace.

- donald


---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message