Ken... I love you man and I trust your judgement... Just do me this favor...whatever you do...make it easy for my little mind to install and configure....pretty please.. And Wiki the hell out of it.
Thanks, -Andy Nicola Ken Barozzi wrote: > > Conal Tuohy wrote: > >> I realise that "blocks" are still vapour-ware, whereas "optional modules" >> are at least imminent vapour-ware ;-) > > > ;-) > >> but I'm still not entirely clear on >> how the relationship between these "optional build modules" and the >> planned >> "blocks" is supposed to develop. Can someone comment on how they see >> these 2 >> related concepts developing? >> >> It seemed to me that the CONTENT of each one of these things (i.e. the >> components, sitemaps, scripts, docs, etc within a module, or block) >> would be >> essentially the same, i.e. they should have the same granularity. This is >> what I meant by "essentially the same", NOT that they use the same >> mechanism, because obviously they are different. Is this right? >> >> When pluggable "blocks" are finally developed, will they be able to >> entirely >> replace the mechanism for optional modules? Or will there be some >> optional >> modules which will never become blocks? Is the optional build going to >> be a >> temporary measure before blocks arrive? Or is it a step towards a >> component >> architecture of blocks? i.e. a block = a module + some metadata? This is >> what I'm still unclear about. > > > I'm too ;-) > > Ok, since I am the one going to make the change to the CVS, and since > with lazy consensus Carsten's who-committs-chooses-the-name, I therefore > hint that I might commit the change in a directory called "blocks". > > Why? > > Simple. > A "module" will soon be a directory that contains > 1) Avalon component(s) > 2) Cocoon component(s) > 3) resources > 4) examples > 5) configuration info > > Example of a jsp module > > 1) org.apache.cocoon.components.jsp.* > 2) org.apache.cocoon.generation.JspGenerator > 3) - > 4) jsp samples > 6) jsp.xconf > > Example of a jsp.cob > > 1) org.apache.cocoon.components.jsp.* > 2) org.apache.cocoon.generation.JspGenerator > 3) - > 4) jsp samples > 6) jsp.xconf > 7) cocoon.xcob (cob descriptor) > > As you see, the only difference is the existence of a descriptor and of > a mechanism for Cocoon to plugin the cob automagically, instead of > during the build. > > So I see this as a first step to blocks. > Once they are refactored in their directory it will be easier to make > the blocks work. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
