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 <igor...@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. > >
