Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Subject: Re: [FYI] www.ormaz.it usecase
From: Jakob Praher <jpraher@yahoo.de>
To: cocoon-dev@xml.apache.org
In-Reply-To: <3E9B421F.3080708@apache.org>
References: <3E9B421F.3080708@apache.org>
Content-Type: text/plain
Organization: 
Message-Id: <1050392520.1016.88.camel@localhost>
Mime-Version: 1.0
Date: 15 Apr 2003 09:42:00 +0200
Content-Transfer-Encoding: 7bit

Am Die, 2003-04-15 um 01.19 schrieb Stefano Mazzocchi:
> Today I went online with my latest creation http://www.ormaz.it 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 [http://www.jjg.net/ia/visvocab/]
> 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
dynamic.


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
flow.

...

>  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 (day.com 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.

thanks.


-- Jakob