Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (nike.apache.org: domain of igorzep@gmail.com designates
 209.85.215.171 as permitted sender)
Message-ID: <4E52DF0A.8020804@gmail.com>
Date: Tue, 23 Aug 2011 01:58:18 +0300
From: Igor Malinin <igorzep@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: "Springification" of C3 - proof of concept
References: <4E37378C.9070302@gmail.com>
 <CAAqLGLPYo7dwFiproO+J8uj5SuFASaKPO9hYfwm54AsVaEH5TA@mail.gmail.com>
In-Reply-To: 
 <CAAqLGLPYo7dwFiproO+J8uj5SuFASaKPO9hYfwm54AsVaEH5TA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2011-08-04 16:08, Simone Tripodi wrote:
> Just my *personal* POV: even if I'm NOT a SpringFramework fan (and I
> won't be :P) your work shall be included in a way or another in C3.
I am not a big fan of Spring also, but in version 3 it got enough to 
jump ahead of many other frameworks. And C3 is heavily based on it 
already... and it uses AOP so much, that it is a pure magic - see my 
other post about a bug on Jetty 7 related to this...

> Anyway I would prefer Spring doesn't play the main role: I mean,
> having 3rd parties integrations it more than fine - we already have
> indeed modules with 3rd parties integrations, like StringTemplate,
> JAX-RS, Optionals (Solr, JAXB) - but IMHO Cocoon *core* components
> should not be dependent by any framework, I wouldn't "force" C3 users
> learning Cocoon AND Spring as a starting point, or require Spring as
> knowledge base to get started with Cocoon.
For the *core* it is perfectly good not to touch it and keep totally 
independent. I am talking exclusively about higher level components that 
are built on Spring already such as cocoon-sitemap and cocoon-servlet. 
Making them play together better, especially where spring-mvc has very 
good functionality is the way to go IMHO. Currently Cocoon does some 
magic on Spring context so that it often gets unusable for other 
applications. Also Cocoon SSF proved to not work for embedding something 
that is not Cocoon sitemap servlet... What I did in the POC is the 
possibility to run C3 pipelines from the Spring controllers, just by 
configuring two servlets in web.xml, but I also would like to have 
possibility to run both pipelines and annotation based spring 
controllers in one URL space, currently they both are separated by some 
prefixes in my example. For this running Cocoon as a Spring-MVC 
HandlerMapping instead of as a servlet should be quite interesting.

> So, my suggestions, if you are happy to continue on contributing - and
> I really hope you are :) - is:
I am doing it for my free-time project, and I decided currently to 
publish everything that could be interesting for the community on 
github. I see many things differently than is implemented on Cocoon 
currently, for example for i18n I prefer some XSLT extensions, not 
separate transformation steps as a more powerful and convenient 
alternative. Yep, powerful in different aspects that i18n transformer, 
as it cannot be used outside of XSLT and bound to specific processor, 
but I need only one (Saxon), and only within XSLT. And I like to have a 
single i18n for Spring and Cocoon, Spring already have interfaces for 
plugging message sources, so why another one in Cocoon... There are many 
other such cases... I'll publish the results as they come, so later they 
can be merged to main cocoon or used as a separate project depending on 
interest and success.

>   * understand how it is actually organized and check what has been
> already implemented (for sure you can help us on improving actual JAXB
> implementation, for example)
For JAXB - I need it in sitemap, so the existing one doesn't suite me, I 
am not sure yet what is the best way to do it, experimenting with 
different strategies...

>   * starting proposing and discussing modifications/additional
> components step by step, not sure everybody would agree on adding
> everything as a single big commit ;)
I'll keep the list updated when some important happens. I also will 
prepare some repos at github that can already be used as dependencies 
and easily monitored for changes. So, everything can be discussed before 
adding something to the main Cocoon project.