Thorsten Scherler schrieb:
[...]
i'm sure JCR will be re-considered (although i would also like to bring
eXist into the discussion).
Actually a while back we decided to go our own route for jcr like with
some other components such as workflow markup, ac, ... My opinion about
this is, it is total overkill and inefficient. We need to maintain too
much medium quality code that is not even lenya specific to solve common
problems that are already solved by specialized OS products.
I share this opinion.
[...]
... and yes we need jcr, now! A CMS without JCR support is doomed.
I wouldn't go that far and consider it doomed. That always depends on
the market, and ATM there are not many serious competitors in the open
source market which support JCR. But of course it would be great to be
ahead of the others.
I expect benefits of JCR integration in the following fields (as defined
in our roadmap):
- Community (increased size and diversity due to positive marketing
effects and better visibility)
- Industrial Strength
- Standards Compliance
- Off The Shelf Components
- Feature Set
The following field might suffer from a negative effect:
- Product Maturity
I'm not sure about the following (might be positive or negative or not
affected at all):
- Low Entry Barrier
- Usability
Other areas with positive effect:
- Code Maintenance
but then there's also the move to cocoon
2.2, blocks and spring - i wonder which should be handled first.
I am using cocoon 2.2 and spring in current project and have ported the
forrest dispatcher as a cocoon block [1]. Moving to cocoon 2.2
architecture in 2.x of lenya is IMO not a priority since it means a
rethinking of many parts of our current use of cocoon.
I agree that moving to Cocoon 2.2 it is not a priority, but for
different reasons. I consider Cocoon 2.1.x a very good product. But I
don't know the changes between 2.1.x and 2.2. well enough to judge the
necessity of upgrading.
then there's people who feel that lenya should become more independent
of cocoon (thorsten and andreas, if i have understood them correctly),
As far as I'm concerned, this is partially the case (see below).
Of the underlying Avalon dependencies yes, further cocoon 2.2 tries to
be more standard like and moving it to spring brings a lot more
flexibility. However my point is that I would like to see that I can
interact with lenya fully via an java api or having the possibility to
switch to another interface.
I have similar feelings. The rendering/GUI layer should be separated
even stronger from the content management layer. One example is the
Lucene integration. We use cocoon:// calls, pipelines, and a transformer
to do the indexing in the content management layer. This generates
unnecessary complexity and a performance overhead and makes it very hard
to handle errors.
[...]
and others (well, me) that think that lenya should become more
cocoon-ish and expose and handle more stuff through sitemaps and
pipelines than it currently does.
I share this opinion when it comes to the rendering and GUI layers.
[...]
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
