cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: "Springification" of C3 - proof of concept
Date Thu, 04 Aug 2011 13:08:03 GMT
Hi Igor!!!
congrats for your committership and your dedication to this work!!! I
really appreciate you shared your results with us!

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.
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.
I think that should sound reasonable, WDYT?

So, my suggestions, if you are happy to continue on contributing - and
I really hope you are :) - is:

 * checkout the latest C3 code from /trunk;
 * 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)
 * starting proposing and discussing modifications/additional
components step by step, not sure everybody would agree on adding
everything as a single big commit ;)

Many thanks in advance, all the best!!!
Have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Aug 2, 2011 at 1:32 AM, Igor Malinin <igorzep@gmail.com> wrote:
> Hello. I've promised some (not so long) time ago to share my experiments
> with C3 and Spring, and now I am ready to show some interesting
> achievements.
>
> Here is the source code:
> https://github.com/igorzep/cocoon-springification
>
> What it does...
>
> 1) Use traditional annotated Spring Controllers
> I think it is better REST than Cocoon today. Those days when Cocoon was a
> leader in this respect has passed, and it really was the best REST framework
> from day one when nobody even used this word. But now Spring is really
> powerful and I think Cocoon should not try to invent own things but
> integrate with Spring as much as possible. In current form it "disables"
> Spring functionality and replace with own much more limited solution.
>
> 2) Use Cocoon Sitemap as Spring View
> Again - traditional Spring way. Also i map Cocoon to WEB-INF so that sitemap
> is hidden for direct browser access (good trick to workaround lack of
> private pipelines in C3).
>
> 3) Use Spring FORM tag library in SAX pipeline
> When it is very simple implementation it works quite good already, much
> better than I expect from it myself...
>
> 4) Integrated Validation with Spring and Hibernate Validator
> Again - traditional Spring 3 way of handling forms, together with previous
> item can be a good foundation for replacing old Cocoon forms module...
>
> 5) EclipseLink JPA
> Just my favorite, as it implements both JPA and JAXB...
>
> 6) Mapping Spring model to XML with JAXB annotations
> Just a quick hack as everything else...
>
> 7) JRebel compatible, just generate rebel.xml for "main" module
> Unfortunately EclipseLink JRebel plugin does not work with latest
> EclipseLink, but can be switched off easily. Otherwise I did a small fix to
> XSLT transformer, so it rechecks for modifications correctly (not included
> with sources) and it works much better than Cocoon RCL. Actually Cocoon RCL
> destroyed root spring context on first invocation and any future requests to
> EclipseLink didn't work at all.
>
> I think that Cocoon RCL should be dropped at all - it is unusable for
> something serious, if you do something more than totally trivial it takes
> more time to fight with it, works almost always incorrectly and saves no
> time as the result...
>
>
> Thanks.
> Discussions and critics are welcome.
>
>

Mime
View raw message