Thorsten Scherler schrieb:
> On Fri, 2007-04-27 at 13:18 +0200, Andreas Hartmann wrote:
[...]
>> Convention over Configuration
>> -----------------------------
>> I used to prefer configuration for a long time for reasons of
>> flexibility, but I kind-of changed my mind. We have to make
>> flexibility trade-offs to accelerate development. The past showed
>> that many configuration options are apparently not important
>> enough to be worth providing.
>
>
> Actually this and all following points depend on which way lenya is
> going. I guess 1.6 would be build on cocoon 2.2, right.
>
> Meaning welcome Spring and goodbye Avalon. This will help to reduce all
> the service manager madness and ease setup of beans via Spring context.
> This will open an new cleaner development of components/modules. Having
> all the configuration you want via Spring context.
>
> A problem that 1.4 has is the tied band with avalon/cocoon.
Yes - in 1.2 we had a looser coupling, but this way accessing
Cocoon components was a PITA. I hope the decoupling will be easier
with Cocoon 2.2 (which is IIUC rather designed for mixed-framework
applications).
> I am ATM
> evaluating different CMS for my current client and one of them is
> Alfresco. Where we use cocoon it uses open office which offers some
> pretty features but unless lenya you can easy develop a standalone
> client to connect to the core and conduct arbitrary tasks, always
> testable via junit.
>
> We need to come back to POJO components that are loosely coupled with
> cocoon as glue, but it should be easy to use struts, jetspeed, ...
> instead to use cocoon to contact lenya. This will reduce as well the
> hundreds of sitemaps/matches we have ATM.
I'd also favor a Cocoon-less content management application ("core").
Some months ago I posted an architecture draft with a diagram attached
which showed a similar layout.
But when we allowing multiple presentation frameworks, it will be very
hard to provide a common infrastructure to build against. Even with
Cocoon there are many ways to build GUIs, and the past showed that
this can lead to a heterogenous codebase which is hard to maintain.
At least in the project itself we have to agree on a particular
view framework, and particular guidelines.
The usecase framework was meant to address this problem, and certainly
reduced it. But it is not flexible enough to fulfil all requirements,
so we still have custom flowscripts for some usecases.
> IMO 1.6 should have a clean (cocoon independent!) core which should not
> contain a web client. The web client should be a module and we would
> provide a cocoon implementation to show how to connect to the core and
> make arbitrary operations.
That sounds reasonable.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
