Re: Unblocking Blocks - microstep 1

2003-02-01 Thread Sylvain Wallez
Nicola Ken Barozzi wrote: Sylvain Wallez wrote: But if you look at SitemapLanguage, which is a subclass of DefaultTreeBuilder, you will notice that its createComponentManager() method creates a new CocoonComponentManager and configures it with . So defines components of the sitemap j

Re: Unblocking Blocks - microstep 1

2003-02-01 Thread Nicola Ken Barozzi
Sylvain Wallez wrote: Nicola Ken Barozzi wrote: 2. Where does the treeprocessor actually create these components? ;-P It seems that methods are calling methods that are... you get the picture... I've got not much time to dwelve into that code, but I looked at the DefaultTreeBuilder.java,

Re: Unblocking Blocks - microstep 1

2003-02-01 Thread Sylvain Wallez
Nicola Ken Barozzi wrote: 2. Where does the treeprocessor actually create these components? ;-P It seems that methods are calling methods that are... you get the picture... I've got not much time to dwelve into that code, but I looked at the DefaultTreeBuilder.java, but still I'm puzzled.

Re: Unblocking Blocks - microstep 1

2003-01-31 Thread Pier Fumagalli
"Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: > Pier Fumagalli wrote: >> >> Somehow, well, yes, but at the same time, no... WEB-INF is (IMO) a hack > > > > Yes, the reliance on web.xml is really ugly and stook because we really > only used it as a servlet for so much time. We have mused somet

Re: Unblocking Blocks - microstep 1

2003-01-31 Thread Nicola Ken Barozzi
Pier Fumagalli wrote: "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: Pier Fumagalli wrote: The only thing I have "against" this is to start thinking about making "WEB-INF" an optional feature (all throughout the code)... It should be a configurable feature. The "web application" concept co

Re: Unblocking Blocks - microstep 1

2003-01-31 Thread Pier Fumagalli
"Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: > Pier Fumagalli wrote: >> >> The only thing I have "against" this is to start thinking about making >> "WEB-INF" an optional feature (all throughout the code)... It should be a >> configurable feature. >> >> The "web application" concept collides w

RE: Unblocking Blocks - microstep 1

2003-01-31 Thread Morrison, John
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > Suggestions? > > The fact is that cocoon.xconf was moved to WEB-INF for > security reasons. > In that servlet environment I would surely move the blocks under > WEB-INF. IMHO it's simple enough to imagine that in all other > environmen

Re: Unblocking Blocks - microstep 1

2003-01-31 Thread Nicola Ken Barozzi
Pier Fumagalli wrote: On 30/1/03 9:09, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: Starting the blocks walk done with microchanges. Yeah! :-) microstep 1: loading of components from blocks -- goal -- The goal is that if I specify:

Re: Unblocking Blocks - microstep 1

2003-01-30 Thread Pier Fumagalli
On 30/1/03 9:09, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: > > Starting the blocks walk done with microchanges. Yeah! :-) > microstep 1: loading of components from blocks > -- > > goal > -- > > The goal is that if I specify: > > >

Unblocking Blocks - microstep 1

2003-01-30 Thread Nicola Ken Barozzi
Starting the blocks walk done with microchanges. microstep 1: loading of components from blocks -- goal -- The goal is that if I specify: then the sitemap processor will * look in WEB_INF/blocks for the block jars * load the bat

Re: UnBlocking Blocks

2003-01-28 Thread Niclas Hedhman
I recalled I saw some comment about specifying version ranges. I would suggest (similar to NetBeans) a comma separated list with an initial operator (>, <, =, >=, <= ) followed by a version. Easy to parse, easy to interpret. >= 1.3.1, <= 1.4.9 also implied rules; = 2 would mean >=

Re: UnBlocking Blocks

2003-01-28 Thread Nicola Ken Barozzi
Morrison, John wrote: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Stefano Mazzocchi wrote: Nicola Ken Barozzi wrote: [...] section, where I can specify the block to use, and the default download location, and the Cocoon components to load. Something like: If you don't spe

RE: UnBlocking Blocks

2003-01-28 Thread Morrison, John
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > Stefano Mazzocchi wrote: > > Nicola Ken Barozzi wrote: > > [...] > >> section, where I can specify the block to use, and the default > >> download location, and the Cocoon components to load. > >> > >> Something like: > >> > >> > >> > >

Re: UnBlocking Blocks

2003-01-28 Thread Nicola Ken Barozzi
Stefano Mazzocchi wrote: Nicola Ken Barozzi wrote: [...] Now, blocks are needed for two reasons: 1 - separate components development and deployment from Cocoon 2 - dynamic loading, polimorphic usage and wizbang super extra inheritance I see the first part much easier to accomplish than

Re: UnBlocking Blocks

2003-01-28 Thread Stefano Mazzocchi
Nicola Ken Barozzi wrote: Stefano Mazzocchi wrote: Antonio Gallardo wrote: I think it is time to start thinking in a plug-in technology for Cocoon. Yes, it's time, but our avalon container is not good enough for that Let's put down what is lacking, and what the intermediate goals are.

Re: UnBlocking Blocks

2003-01-27 Thread Nicola Ken Barozzi
Nicola Ken Barozzi wrote: Given that Fortress is ECM2, and given that we are going to release soon, Avaloners Being multiproject %-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - ve

UnBlocking Blocks

2003-01-27 Thread Nicola Ken Barozzi
Stefano Mazzocchi wrote: Antonio Gallardo wrote: I think it is time to start thinking in a plug-in technology for Cocoon. Yes, it's time, but our avalon container is not good enough for that Let's put down what is lacking, and what the intermediate goals are. Avalon will do this now: -