cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Malinin <igor...@gmail.com>
Subject Re: "Springification" of C3 - proof of concept
Date Mon, 22 Aug 2011 23:52:04 GMT
On 2011-08-05 15:33, Nathaniel, Alfred wrote:
> It's a nice show case that C3 has reached one of its design goals to
> be embeddable in other frameworks.
Unfortunately it is not so easy, there are just too many corner-cases 
that makes using Cocoon together with Spring difficult. But I will try 
my best to make it easier.

> Whilst C2 is the 500lb gorilla squatting the driverseat, C3 is a neat
> little monkey who knows how to driver but also fits onto the backseat.
Finally happened,  I waited for cleaning up dependency hell from the 
very first versions. :)

> I was first confused by the term "springification" which I understood
> as using more Spring in C3.  In fact it is the other way around.
> It should rather be called the cocoonification of Spring.
Spring is already matured project that provides all the flexibility to 
plug into it. Cocoon 3 is a new child yet. By springification I meant 
making Cocoon and Spring better friends than they are today (many seem 
turn to Wicket as a new buzzword, but honestly I cannot see anything in 
Wicket that is useful for Cocoon - all the things that better in Wicket 
compared to other frameworks, are simple the best in Cocoon itself - 
because of pipelines). I simple do not want to loose all the goods of 
Spring if I chose to use Cocoon! Especially when Cocoon itself is built 
on Spring :)

> Calling C3 pipelines from frameworks such as Spring MVC is a welcome
> perspective for people who are stuck to an MVC framework but want the
> power of Cocoon plumbing for the rendering.
I am not stuck, for me it is a new project, but I don't see how Cocoon 
(or other alternatives) will help me to do actual job on the request 
better than Spring. Cocoon does rendering perfectly, and there is 
nothing more needed if you only retrieving some data, but when I want to 
execute some logic, hacking pipelines with actions is not appropriate 
solution, especially if almost any action can choose from several 
pipelines as a result.

> But saying that our neat little monkey should stay on the backseat
> because Spring knows so much better to drive is too restrictive.
> C2 has many more use cases than just REST and MVC and C3 should be
> able to drive these as well.
I don't see any problem with this... BTW what use case is restricted by 
my ideas? If you are talking about Cocoon SSF - it is a nice idea, but 
does anybody uses it for something except most trivial stuff? I believe 
C2.2 has not so much users, most are using C2.1 still. And from the 
quality of SSF I can conclude it is not used too much except the basic 
things, just to run pipelines. May be it is just me so unlucky to meet 
all the bugs in it... but I hardly believe in it.

> I think your POC is worthwhile keeping but certainly not in C3 core.
> I wouldn't even put it under cocoon-samples because it gives the
> wrong impression that one has to swallow Spring before tasting Cocoon.
Again isn't C3 is based on Spring heavily already? Why learn some 
undocumented Cocoon where we have perfectly documented Spring. I am 
talking only about the components where the Cocoon already has a 
dependency on Spring or where Spring already have good mature things 
that are known to much wider audience compared to undocumented Cocoon 
internals. I am not a fan of Not Invented Here Syndrome. If Spring 
provides something that is better than you can find in Cocoon, why not 
use it?


Mime
View raw message