cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <>
Subject Re: [FYI] usecase
Date Tue, 15 Apr 2003 07:42:00 GMT
Am Die, 2003-04-15 um 01.19 schrieb Stefano Mazzocchi:
> Today I went online with my latest creation which is
> entirely based on cocoon 2.1-dev compiled today. This says it all about
> how confident I am about the code we have in CVS.
> I want to tell you how I did it and why I choose it.
thanks for the info. And thanks for sharing it with us.

> The site is very small. The IA diagram []
> lists no more than 10 different pages or decks of pages. Moreover, I've
> done *all* the work by myself. Everything, from taking the pictures,
> graphic design, CSS/HTML creation, programming, installing.

Not bad - the site looks really nice.

>  b) flowscript rocks the planet. it will rock even more combined with
> hot-deployable avalon components.

been thinking about this for a long time ... 
It would be interesting, what we need in order to have hot-pluggable
avalon components - afaik it would not be that hard, the hardest problem
ist the current EMCs way of getting component information (from the
monolothic .xconf). 

What are the most difficult points here - I guess the component reload
order and dependencies among different components.

I thought about differntiation between the core (sitemap processor, etc)
and custom components, that could be more easily reloaded and thus more

For instance for blocks I would keep things simple ( kiss you know ),
all we need is something like:

interface BlockDeployer{ 
	void insert( Block aBlock ) throws DeployerException;
	void update( Block aBlock ) throws DeployerException;
	void remove( Block aBlock ) throws DeployerExcpetion; 


I think we could learn much from the Kexts (MacOS Kernel Extensions) or
Linux Kernel Modules ( insmod, rmmod, ... ).

Sorry for being so evocative again. (but dreaming of cocoon blocks or
plugins for a long time now ... )

Whats your opinion, state of mind on this?

>  d) flow + inputmodules + redirection from flow totally substitute the
> need for actions in the sitemap. The elegance of the resulting solution
> is not even close to be action-based equivalent.

sounds interesting. I will try to update my expermiental projects using


>  f) cocoon needs an xml repository as an avalon component accessible
> from the flow! the use of protocols is simply not enough for the kind of
> data manipulation required in seriously roundtripping webapps that have
> to mix, match and change stored xml content. This doesn't need to be an
> xml database, it could be a virtual file system on top of a blob-capable
> DB or a CVS view.
wondering about slide and jsr 170 - there are interesting things going
on there recently ( has contributed a ri for jsr 170).

I am evaluating slide for a cms system now. But have not had time to
play with slide + cocoon.

> Hope this helps.


-- Jakob

View raw message