cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Flow as a block
Date Fri, 14 Mar 2003 13:49:31 GMT
Nicola Ken Barozzi wrote:
> 
> 
> 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 
> removed
> 
> Ok.
> 
>  - people don't like/use actions and would like to see support for it 
> removed
> 
> ? I regard actions on par with all other Cocoon Sitemap Components. 

I, for one, don't.

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

But I would like to be able to build cocoon without them and prevent 
people with the ability to use them to solve their problems. Just like 
Carsten wants to do with the flow or XSP.

>  - 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?!?

Yes, tricky. I wonder how useful instrumentation is given that java 1.4 
has pretty damn serious remote debugging interfaces.

> 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/modules/flow
> ./src/modules/servlet-environment
> ./src/modules/cli-environment
> ./src/modules/bean-environment
> ./src/modules/instrumentation
> ./src/deprecated  <-- move it here for consistency
> ...

it doesn't matter where we put it, but how we do it.

removing actions and the flow is just a matter of moving classes and 
patching the treeprocess configurations. xconftool can be used for that.

removing XSP and the compiled language components can be done by moving 
them and patching the configurations with the xconftool

I don't know about the servlet dependency.

I have no idea on the instrumentation since we might require to 
'aspectize' our code and this means java pre-processing and I don't 
think I like this approach. What about virtual AOP thru proxies? but 
that should be something done by the classloader, I think...hmmm.



Mime
View raw message