cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Back from Germany
Date Wed, 30 Oct 2002 09:27:14 GMT
Stefano Mazzocchi wrote:
>
> All right, I'm back from Germany.
>
I hope you had a nice and easy trip back without any storm!

>
> Anyway, I won't go over everything that happened there, but the
> important thing for us is that I finally managed to explain the block
> concept to Carsten the way I intended it.
>
> And he loved it :)
>
Oh, you know - I had to directly confrontated with you in person :)
No, just kidding - I really can value it now. I misunderstood the
concept in the first time and now after realizing it, I can't wait
that you start implementing it ;)

> We agreed not to start implementing it until 2.1 is out but we outlines
> the system so that it minimizes the impacts on both the current
> architecture and, more important, on the usability of Cocoon in general.
>
> The idea is to give the users the ability to move to blocks in a very
> easy and natural way. That is:
>
>   phase 1) use Cocoon as you do today. You won't be forced to use blocks
> if you don't need them or you don't understand them.
>
>   phase 2) use blocks just for deployment. This is mostly similar at WAR
> files today: just package your stuff as a block and deploy it on a
> running Cocoon.
>
>   phase 3) use blocks for deployment and depend on other blocks. This
> will work sort-of APT-get: when you deploy your block and you need, for
> example, FOP, Cocoon will deploy your stuff and then go looking for the
> FOP block and deploy it for you. Of course, the behavior will be all
> user-selectable and all that but that's the general idea
>
>   phase 4) users will start providing their own blocks to others to
> depend on.
>
> Also, we planned on having a web interface on top of Cocoon for
> configurations and for block deployment. Of course, all secured and
> possibly to be turned off for production environments.
>
And this is the part where we spend most time, because this is the interface
to the Cocoon user. This has to be very clear and simple but of course
powerfull.
And the great thing is, that this web interface will be developed using
Cocoon and it's components. So it is also a good presentation of Cocoon
itself: we can show flow script, svg generation etc.

Carsten


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


Mime
View raw message