Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44420DA2.9020001@nada.kth.se>
Date: Sun, 16 Apr 2006 11:25:54 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Mini-Cocoon
References: <A955EA1F8FE31749AEC8C998082F6C7C41A90F@hai01.hippo.local>
In-Reply-To: <A955EA1F8FE31749AEC8C998082F6C7C41A90F@hai01.hippo.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Max Pfingsthorn skrev:
> Hi!
> 
> I really like the idea to make cleancut interfaces between core components and factoring them out.
> What I would really look forward to would be an abstraction of the processor level.

There is already a well known API for that: the servlet. We have had a 
number of discussions about using Servlet instead of Processor. The 
blocks architecture is based on servlets as processing level abstraction.

> That would allow
 > us to do cool rails-like things by implementing an MVC processor :). 
Berin hat this idea a
 > while ago [1]. Having a processor implementation would allow us to 
simply <map:mount> an mcv
 > component into publishy sitemap uri spaces, for example for the 
ever-recurring polls and so on,
 > while not polluting the sitemap language. Flowscript might be ok for 
smaller controlling needs, but
 > I think a dedicated java implementation would go a long way. Think of 
debugging for one thing.
 > Integrating Javaflow would be nice though for the stateful controllers.

You are going to like the blocks architecture, the block protocol 
already do what you are asking for see 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114237414521595&w=2 for 
the current state and for more about the block protocol.

/Daniel