On Wed, 21 Aug 2002, Nicola Ken Barozzi wrote: > > Giacomo Pati wrote: > > 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? > > The second you said. > > > 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. > > Blocks are not set in stone, and now Cocoon is in Alpha.
It doesn't have to do with "caved in stone" or development stage? > Since these "modules" will become functional blocks, I want to go right > away with the terminology. > > >>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? > > I never talked about this stuff, I just mean that *whatever* mechanism > will be used, the dir layout of the blocks will not change. > It's just a matter of defining these specifics, adding them to the build > process. Ok. > >>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? > > To be honest, I do not have a particular architecture in mind, I was > talking about the build. > > But if I have to say mine on blocks, I think that the easiest thing that > can be done is to start very lightweight, and implement one feature at a > time. Why and which? > > <>>>>>>>>>>>>>>>>>>>>><>>>>>>>>>>>>>>>>>>>>>>> > > The contract/interface of a block is the union of all the descriptions > of what it exposes: > > >> 1) Avalon component(s) > > Not exposed, but Cocoon must be able to merge the supplied xconf with > the Cocoon one. Merging is one way, a hierarchy of Containers/CM/SM the other. > In the future we should separate them from cobs and have Cocoon work ala > Merlin via dependency descriptors. No, they are part of cobs. > But if we buy in this too soon we would just loose time, without real gain. Can you explain? > > >> 2) Cocoon component(s) > > Cocoon components will be automatically available as declared in the > root sitemap.xconf. You think of a new config file (siteamp .xconf)? Cocoon components aren't defined in sitemap.xmap but in cocoon.xconf. You are confusing me. > Similar to what done with the Avalon ones. > > >> 3) resources > >> 4) examples > > Simply an URI set of values for the files and the list of the sitemap > snippets that can be called, with human-readable description of what > these do. > > > All this would make the system usable right away without big problems, > refactoring or design discussions. > > Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
