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?
