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.
