cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lowe <>
Subject Re: [RT] How scripting made me hate java
Date Wed, 16 Feb 2005 10:01:40 GMT
As someone who's walked into a cocoon project over the last few weeks,
I don't have a problem with the usage pattern as such (sitemap.xconf,
flowscripts, cforms etc). Most of the problems I've had have been to
do with some of the crack-induced choices made by other parties (I
wont go into details).

The thing that I've found the most fustrating with cocoon itself is
the build process. I'll familarise myself more with the source and see
whats going on with the project some more and have a better idea why
some of the idiosyncracies are as they are with cocoon.

The lack of unit testing for flowscript I'd say is a big problem,
proving something works is important. The other problems I imagine are
down to not having dug up the right documentation yet.


On Wed, 16 Feb 2005 10:13:32 +0100, Carsten Ziegeler
<> wrote:
> <SNIP/>
> I agree with most points from Stefano and we see it each time we do
> Cocoon training that it's very hard for new users to start with Cocoon.
> Imho that's a main difference between Cocoon and other projects: with
> other projects it's very easy to start, but you might get stuck later on
> in your project. With Cocoon it's very hard to start but as soon as you
> get how it works, you're very fast. In our trainings we see this as
> students start to understand most parts on the second day and start
> having fun and get "productive".
> Yes, documentation isn't the best and a starter's guide would imho help
> here. Adding new features most often comes with no documentation, so
> while the code base is growing the docs are not.
> I have the feeling that we leaned back in the last years saying "we are
> the coolest on earth" while we absolutely ignored that the world around
> us changed/moved on: people started using different things like Spring,
> Hibernate and AOP. And because of our nice "winter sleep" we are now way
> "behind" other solutions in some areas - of course we are still ahead in
> some other aspects. I don't say that we should just do it the way others
> are doing it, but we should go through the world with open eyes and
> should listening.
> When you're doing a lot of projects with people involved that don't have
> that deep knowledge of Cocoon, you soon see what would help them: there
> are two main topics: building and configuring - there are so many
> different ways of building Cocoon; I guess each of us has his own best
> practice and don't provide one single solution to the users. Just look
> at the wiki and see how many solutions are listed there.
> So we have identified a lot of different issues that could be fixed. BUT
> what are we really doing against it? We are endlessly discussing things
> since years: how things *should* be, how things *could* be etc. And the
> discussions end most times with everyone nodding his head "YES, that's
> it, we *really should do this*". And then everyone just goes home and
> hopes that someone else is doing the work.
> But obviously just discussing things doesn't fix anything - so we need
> people doing something apart from just discussing. And imho it doesn't
> matter if during the development Cocoon isn't working for some days or
> if a feature is added that isn't that optimal. We are talking about our
> "trunk" which is our development branch; so we can do whatever we want
> there and if we think that something shouldn't stay there, we can simply
> remove it. We don't have to take care of potential users of the trunk.
> With 2.1.x it's totally different of course, we should be very carefully
> when adding/changing things there. We *never* should introduce
> incompatibilities there.
> So, my opinion is we should just look at what people want to use, what
> *we* thing is the best to have, combine those two and then: just do it.
> The past showed that first discussing things lead to no code while first
> coding somethings and then start a discussion based on the code works
> very well. Even if the code is totally changed or removed, it seems to
> be the better way.
> And this is what I'm currently trying to do: I'm doing a lot of projects
> with Cocoon and I'm talking to many users of Cocoon. While they use
> Cocoon in different areas, they all have the same problems and even we -
> working with Cocoon for nearly 5 years now - have similar problems. So
> I'm taking the feedback, add my own thoughts and implement ideas to see
> where this may lead. With the current core we have a good base to
> implement new things. It's our own code and we can add new features like
> AOP or JMX support there without any problems.
> But if I have to discuss each and every feature with 20 people -
> everyone having it's own ideas - I'm most times blocked: 5 people like
> the idea, 3 people don't like the idea and so you're doomed.
> And please: don't get the impression that I'm saying "I'm the only one
> doing work in Cocoon and you all are not". That is totally wrong, I'm
> not the only and others are doing great work in Cocoonland as well. But
> I can only write about myself, I don't want to point any fingers.
> Once Stefano said something about trying to push people out of their
> comfortable chairs and trying to push them. While I wasn't very happy
> about that statement when he made it, I think this is what we really
> need: people doing something.
> Real blocks are a very very cool feature. The first time Stefano
> mentioned it, I wasn't sure if someone really needs it and in fact I was
> against it. Then Stefano visited us on a nice stormy day in Paderborn
> and I started to see the potential of real blocks. But although they
> might help on the long term, I fear the complexity they add. For new
> users looking at Cocoon, it will become much more complicated and
> disturbing (at least that's what I fear) - so this is one of the reasons
> while I'm not that active in that area. I think we should just make
> little improvements that make using Cocoon much easier.
> I still hate flowscript :) When you're used to Java development with
> Cocoon it's really hard to get your flow script working, because you're
> using different apis, have different objects, don't have access to
> specific things (like the object model) and then you start writing a
> *very interesting code mix* of flowscript and java. So I personally
> would like to trash the javascript on the server side while replacing it
> with the Java variant :)
> So in the end imho it's really easy: let's work together on the project
> and improve it. Listen to users and see what you can do about the problem.
> Carsten
> --
> Carsten Ziegeler - Open Source Group, S&N AG

View raw message