cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Flow as a block
Date Fri, 14 Mar 2003 09:54:37 GMT

Stefano Mazzocchi wrote, On 14/03/2003 10.31:
> First of all, there is a major architectural difference between moving 
> the portal-framework into a block and moving flow into a block. Why? 
> because the first is 'on top' of cocoon, the second is 'in cocoon'.

Nicely worded. I agree.

> Now, I agree with Carsten that there are people that don't like some of 
> the cocoon functionalities and would like them removed. 

Yes (this is the need we need to solve, let's look at the solution)

> So, since these are RT, let us say that we have:
>  - blocks -> things that implement functionality on top
>  - modules -> things that add functionality inside
> why this difference?
> Because I expect the number of blocks to grow wildly in the next few 
> years, but I DO NOT want to see modules grow wildly or this will only 
> reflect on poor ability for us to define, document and validate them.

Here it is. It's the same conclusion we had come to some time back, but 
now things are more clear and IMHO the time is more "right" now.

>                                  - o -
> So, how do we do it?

Ok, let's see them one by one:

  - people use cocoon in a non-servlet environment and would like to see 
all servlet hooks removed

See the thread (In)Dependence on servlet, IMHO it's big enough to want a 
separate thread.

  - people don't like/use XSP and would like to see dependencies on java 
compilers removed

Agreed. Now that the sitemap is not compiled, it makes sense.

  - people don't like/use the flow and would like to see support for it 


  - people don't like/use actions and would like to see support for it 

? I regard actions on par with all other Cocoon Sitemap Components. They 
are part of our basic sitemap contract IMHO, I would keep them in, also 
because it does not bloat Cocoon or add additional dependencies.

  - people dont' like/use the avalon instrumentation and would like to 
see support for it removed

This is tricky, Instrumentation is an "aspect", and thus cannot cleanly 
be separated ala OOP. How do we do this?!?

All the above can be done, but a question remains: how do we physically 
manage them?

That is, I propose the we simply compile them as the blocks are compiled 
now, with explicit dependencied and needed jars, the compilation 
exclustions, and samples...

Shall e have a .src/modules/** hierarchy?

./src/deprecated  <-- move it here for consistency

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message