cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?)
Date Mon, 17 May 2004 20:51:12 GMT
Ugo Cei wrote:
> Il giorno 17/mag/04, alle 16:53, Berin Loritsch ha scritto:
>> OK, now to the topic of IoC, Serviceable, etc.  This is a fundamental
>> change to the framework that you may are suggesting.  Such a change is
>> not easy, and can be considered harmful unless you design your container
>> in a way to support heterogeneous component types.
> 
> Just to be clear: I'm not going to write a container any time soon. I 
> don't have neither the time nor the necessary architectural and coding 
> skills. I just started evaluating Spring for implementing the Model part 
> of an MVC application that we are developing (V+C is Cocoon with 
> Flowscript, obviously) and I like what I see. At the same time, I don't 
> like some of what I see in the usage of Avalon in Cocoon. Spring is a 
> well-established, well-documented product that is rapidly gaining 
> popularity and is being put to test in writing real applications (I'm 
> not implying that Avalon isn't) and we might learn something from it.

Well, I will say that it looks like Cocoon has its own container, which
is fine.  If enough people want to adapt that container to different
component models then we need to look at that.

> (As an aside, Spring's lead developer thinks checked exceptions are 
> evil, so I like the guy ;-) )

I, personally, am somewhere in between.

> And yes, this is a fundamental change. We started discussing fundamental 
> changes since Stefano's "On building on stone" RT, but discussion has a 
> little subsided since then, so I'm trying to revive it.

I thought the idea here was to have Cocoon hosted on its own container,
initially based on ECM style code and adapted better to Cocoon's needs.
This much has (I believe) happened.

>> You might want to take some inspiration from my Dojo project (note I
>> said inspiration--I am not suggesting you depend on my code unless you
>> feel it truly merits it).  The concept that I am designing and
> 
> I've been following Dojo through your blog, but I must be sincere: I 
> don't have the time to look at its code. I am looking at Spring with 
> some interest because, as I said above, I'm using it in a real project, 
> and that's all.

I understand.  I wasn't so much suggesting looking at the code but the
design principles.  The only way heterogeneous component types would
work in a Cocoon environment is employing something like what I
suggested.  Granted there may be other ways, but IMO that is the most
easily sustainable way.

I will say that initial experimentation with writing components in
different styles I like certain aspects of Spring, Pico, and Avalon
style components--although I must admit that the initial romance of
King Author's court has worn off.  In the end, the direct injector
style of component works quite well, and is quicker than Avalon
components for startup times.  Why?  The answer is simple, the component
has less to do.  With Avalon, you are given an artifact that you must
now read and interpret at runtime.  So instead of just one read and
interpret cycle (i.e. the reading of a configuration file or something
similar) we have two (one for the config file and one for each
component).

This also leaves allot for the component to have to deal with if
something is not right.  As you can imagine, some components are well
designed and have well thought out error messages and failure
notification while other components don't.  You can't easily codify
an "aspect" that can be applied across all components because the
mechanism to set values is different.  This is probably another area
where you enjoy Spring style components.

The end result is that with components that are set up much quicker,
the need for pooling components becomes less of a need, and it is more
reasonable to use singleton and transient style components.  Another
benefit we all enjoy is simpler code as we no longer have to surround
our lookups with try/catch/finally--although it is still necessary for
database code.

Lastly, I find that testing spring/pico style components is much much
easier as I can inject my mocks directly into the component to test
its functionality.  This combination makes a strong case for the Spring/
Pico style components, but again, providing native support for it in
Cocoon will not be as straightforward as it could be.  Changes to the
core of a framework or application should be done with great care--but
don't be too afraid to do it.


Mime
View raw message