On Mon, 19 Aug 2002, 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".
Please wait a minute. Are you implementing a Cocoon Block infrastructure as proposed by Stefano or are you modularizing the build process similar to avalon-excalibur? Don't use the block terminology for something still in the mind of Cocooners like Stefano, me and probably others for something that doesn't fullfill the expectation. > 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. Ok, can you elaborate more on this mechanism of deployment/plugin? Is there an abstraction possible for Block interfaces and Block implementations so that Cocoon (or a user) is able to choose between different implementations of a Cocoon Block Interface? Does this mechanism support hot deployment of a .cob over the wire? > 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. Well, this is easily said but could you tell us more about the architecture/design you have in mind? Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
