Our use case: have a simple way to transform xml documents into html in an ant-enabled way.
Anakia's target use case: have a simple way to transform xml documents documents into html in an ant-enabled way. Cocoon's target use case: create a dynamic performant website aggregating data from multiple formats and places and output in a variety of formats using arbitrarily complex business logic. (so its not correct and I didn't bother to look it up, but hey ;) Anakia is good at what it does, as is cocoon. Until there is a cocoon component that fills the same use case as anakia does, anakia is the better choice. Has nothing to do with the quality of either, imo. BTW, I'm probably getting a green light to use cocoon as the content delivery system part of a tomcat based content management system. Finally I get to use some jakarta and xml@apache code where it matters =) regards, - Leo > -----Oorspronkelijk bericht----- > Van: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Verzonden: Thursday, March 21, 2002 2:56 PM > Aan: 'Avalon Developers List' > Onderwerp: RE: Cocoon 4 docs == complex > > > > From: Peter Donald [mailto:[EMAIL PROTECTED]] > > > > Hi, > > > > I just went to redo the excalibur projects documentation and > > found that it is > > extremely complex to setup and use. You have to go download a > > 14MB file and > > do all sorts of munging to get things working and it is in no > > way shape or > > easy. Even then it spits out mountains of debug and warnings > > about things > > that I am not using etc. > > > > Compare this to Anakia > > > > <taskdef name="anakia" > > classname="org.apache.velocity.anakia.AnakiaTask"/> > > > > <anakia basedir="${xdocs.src}" destdir="${docs.dir}/" > > extension=".html" > > style="./site.vsl" > > projectFile="stylesheets/project.xml" > > includes="**/*.xml" > > lastModifiedCheck="true" > > templatePath="my/path/stylesheets" > > > </anakia> > > I hear your pain. Cocoon also has heard the cry, and is working > on making a minimal solution that does not have a 14 MB chunk to > download. In essence they are wanting to componentize web applications > so that you have the Cocoon core, and whatever component you need. > > For us, this would be the Jakarta styling component.... > > The process is not finished yet, and may take some time. > > Here is the bottom line: > > 1) Cocoon is a powerful concept--esp. for dynamic information. > 2) Cocoon is very heavy for the command line. > 3) All we need is XSLT and FOP--we have defined "pipelines" > > For the short term, I would not be offended if we used the > <style/> tag for straight XSLT transformations (our resulting > info would be pretty much XHTML 1.0 compliant (except we may have > some additional tags...) > > We could theorhetically generate the PDF by directly invoking > FOP to generate it. For our HTML docs, this approach would be > the least painful. > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
