Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4442B977.5080200@apache.org>
Date: Sun, 16 Apr 2006 23:39:03 +0200
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Mini-Cocoon
References: <1c661f2f0604141213laae0c5fi34749936fb73ab16@mail.gmail.com>
In-Reply-To: <1c661f2f0604141213laae0c5fi34749936fb73ab16@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Don Brown wrote:
> For the next generation of Struts Action Framework, we have merged
> with WebWork to build the new version on its solid foundation. One of
> its powerful features are its Interceptors, which act like Servlet
> filters allowing you to define the framework workflow for the Action
> on either a per-action or per-package basis.  This lets you fully
> separate the concerns of your framework logic.
>
> I've been toying with the idea of bringing the Interceptor concept to
> the view layer, and with XHTML becoming more and more prevalent, I
> think it is ripe to bring the power of the Cocoon pipline to post-page
> processing.  I'd like a user to be able to specify an interceptor
> stack (pipeline) on a per-action or per-package basis.  This would be
> similar to the popular Sitemesh project, but more powerful has any
> page minipulation is possible.
>
> Anyways, I bring this up here because it would require a SAX-based XML
> pipeline implementation and I immedately think of Cocoon.  However,
> the requirements for such a feature would be:
>  - We only need transformers and serializers, the framework would
> handle the generation (implicitly a SAX parser generator would be used
> to process the response's outputstream)
>  - Ideally no additional dependencies
>  - The pipeline impl should be small, and focused
>  - Very little to no additional configuration for the user.  A set of
> transformers and serializers would be defined somewhere, and stacks,
> or statically defined pipelines.  No selectors, matchers, or other
> sitemap capabilies would be needed.
>
> We could write our own, but part of the vision of Struts Action 2 is
> to bring some level of unification to the Java web development space,
> and I'd like to include Cocoon in the discussion.  I have a Cocoon
> pipeline extract project, Simple XML Pipelines[1], we could use, but
> I'd rather use an "official" Cocoon artifact to strengthen the ties of
> the two projects and leverage the years of experience and knowledge of
> the Cocoon community.  My pipelines project could be donated, if
> necessary, to seed the work.
>
> This new Struts Action 2 feature hasn't been discussed, much less
> accepted by the project, still in its infancy, but I wanted to first
> float the idea to see if the Cocoon community would be interested in
> developing such a "mini-Cocoon".  I've found several uses of my
> stripped down Pipeline project in areas like multi-versioned SOAP
> services support and portal URL-rewriting, so I think it would be of
> interest outside Struts.
>
> Look forward to the feedback,

Splitting Cocoon in smaller pieces is something that absolutely must be
done IMO if we want Cocoon to evolve. This has been discussed many times
on this list and your deconstruction of Cocoon for use in Struts
(flowscript and now pipelines) shows well that Cocoon will be copied
rather than used if it stays the monolithic piece of code it is today.

Sylvain

-- 
Sylvain Wallez - http://bluxte.net