cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <m.pfingsth...@hippo.nl>
Subject RE: [RT] Mini-Cocoon
Date Sun, 16 Apr 2006 08:30:06 GMT
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. 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.

Bye!
max

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112869422207312&w=2

> -----Original Message-----
> From: Daniel Fagerstrom [mailto:danielf@nada.kth.se]
> Sent: Saturday, April 15, 2006 14:01
> To: dev@cocoon.apache.org
> Subject: Re: [RT] Mini-Cocoon
> 
> 
> Bertrand Delacretaz skrev:
> > Hi Don,
> > 
> > Le 14 avr. 06 à 21:13, Don Brown a écrit :
> > 
> >> ... - We only need transformers and serializers, the 
> framework would 
> >> handle the generation (implicitly a SAX parser generator 
> would be used 
> >> to process the response's outputstream)
> >>  - Ideally no additional dependencies
> >>  - The pipeline impl should be small, and focused
> >>  - Very little to no additional configuration for the 
> user.  A set of 
> >> transformers and serializers would be defined somewhere, 
> and stacks, 
> >> or statically defined pipelines.  No selectors, matchers, or other 
> >> sitemap capabilies would be needed. ..
> > 
> > What you suggest echoes our discussions from a last 
> December [1], and I 
> > think there's definite interest in our community to see 
> Cocoon delivered 
> > in smaller independent packages. At least at the "talking about it" 
> > level...but let's hope your message prompts some people to stand up.
> > 
> > Maybe some of the people working on 2.2 can comment about this? How 
> > could the new structure of 2.2 help using our sitemap 
> components outside 
> > of Cocoon?
> > 
> > Personally I'd love to help, but to be realistic I won't be able to 
> > commit serious time to such a project in the next few weeks. Except 
> > maybe mentoring or co-mentoring a Summer Of Code project to 
> experiment 
> > with refactoring some of our sitemap components to be usable in a 
> > lighter environment.
> > 
> > -Bertrand
> > 
> > [1] 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113380354129554&w=2

Splitting Cocoon core is on my todo-list, I wrote something about it a 
while ago: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113682736011081&w=2.

An important question is of course what blocks to split core into and 
what the contracts should be for these blocks.

/Daniel

Mime
View raw message