cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <scher...@gmail.com>
Subject cocoon migrate from 2.1 to 2.2 or 3 (was Re: Forms and maps)
Date Wed, 18 Apr 2012 15:07:53 GMT
The whole thread had changed the subject a long time ago ...

On 04/18/2012 03:29 PM, Mark H. Wood wrote:
> On Wed, Apr 18, 2012 at 11:34:26AM +0200, Derek Hohls wrote:
>> It all depends on your environment and the "rate of change". There are
>> many back-end systems (running on old but reliable technology) that
>> hardly change at all.  However, the web (and now tablets/mobile) has a
>> very high rate of change (and expectation of change).  The point here is
>> that by using more loosely-coupled modules then you will only have to
>> change the parts that really need to be changed; a monolithic approach
>> is less amenable to that.
> I think this may actually underscore the O.P.'s point.  Changing the
> whole world in one go is the monolithic approach.  The modular
> approach would enable choosing new mechanisms for new work and
> sticking with old, established mechanisms for existing, still-useful
> work when that makes sense.  Having to throw out piles of satisfactory
> working code just to use a dependency version that still has the
> attention of its maintainers is really unwelcome.
>
> I think the complaint is that Cocoon 3 is really Butterfly 1.

Well, yes and no.

If you have experience with c2.x you can do close to the same thing on 
c3. Most of the pipelines i saw are pure generator -> xsl transform -> 
serializer stuff that has not changed a bit.


Yes there are some components not yet migrated but we are an open source 
project and welcome every patch. However the basic idea from the start 
of 2.1 blocks had been to slim down cocoon. c3 is the consequence of 10 
years of "slim" down.

To pin it down on a concrete code example if you wanted a specific 
component in c2.1 you needed to get hold of an avalon manager, ask the 
manager to lookup your component (or additional ones to do the final 
lookup). Every component needed to be configured and registered with the 
manager. Leaving your 20 lines of code being 90% boilerplate code.

In comparison in c3 you do
@Autowired
@Qualifier("messageSource")
ReloadableResourceBundleMessageSource messageSource;

To inject your variables and creating a setter you are not forced to 
even use spring BUT you can still reuse your code. ...and best NO 
boileplate code, resulting is much cleaner code.

I had chosen c3 as  base framework for our current project because that 
allowed me to have pure java devs in my team that never worked with 
cocoon at all and they were productive since day one (which is not 
possible in 2.x having made that experience in other projects).

Bottom line regarding forms handling html5 + ajax framework + your js + 
css as view technologies and c3 rest service as form action handler is a 
beautiful base due to various reasons:
- mobile ready (you can even use even generic app generator to create 
native android, etc. apps without writing a single line of code)
- REST services are not bound to c3
- REST services can call or even dynamically create c3 based pipelines.

-- 
Thorsten Scherler<scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>

http://www.codebusters.es/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message