On Tue, 20 Aug 2002, Marcus Crafter wrote: > On Tue, Aug 20, 2002 at 09:07:16AM +1200, 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'd always envisioned Blocks to be a better way to architect and > design your application (more on the side of large scale apps > rather than small), whereas Modules being the ability to plug > functionality into Cocoon to keep the core small and to be > able to package your application with what you need rather than the > whole Cocoon distribution.
And Blocks have abstraction in mind. A interface definition (this is not a java interface but something more of that concept of meta data definition) gives an other Block the possibility to "programm" against it. The deployer is free to choose whichever implementation of that interface he likes (if there will be more than one). See my mail here http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102941595120561&w=2 > I see modules containing particular pieces of functionality, a jsp > module, a fop module, a db module, etc, with each module > containing its relevant libraries, default configuration, class > files, etc. Samples could also be packaged within the module, but I > think that's really only relevant for the sample webapp (?). > > Importing the module into your Cocoon distribution automatically > makes it available for use in applications. Essentially your > Cocoon installation becomes the core, plus the modules you require > for your app. > > Blocks however, I thought were more at the level of the > application being developed. Think of a large site like sun.com or > amazon.com. Blocks would allow the separation of the individual > constituents of the site, similar to subsitemaps, but could also > include xml/xsl/html/components/etc relevant to that part of the > application. > > Note that this is separate from Modules - a particular block might > require particular modules to be present for its features to work. As well as other blocks. > Blocks can have dependancies and can communiate with other blocks via > sessions, etc, The proposed way for inter block communication was a protocol like "block:skip:/adtd2html" for easier separation of interface and implementation. > but essenentially dropping a Block into your Cocoon > distribution reserves a part of the uri space for that Block to > use, kind of like the Tomcat webapps directory. I also thought that > Blocks could include particular Modules if necessary. eg. part of a > stocktrader site that generates pdf reports would only require the > fop module at that level. So which is your distinction between modules and block than? In your explanation they overlap but in "size", right? > I think there were also discussions/thoughts about having > hierarchical blocks, meaning you could place common parts of > your application at a higher level with lower level blocks depending > on it (ie. not needing to have common classes/files duplicated). > There was also some talk of remote blocks, ie. being able to > reference a block running on another server. > > Regardless of if/how it happens, I think the concept of modules, > essentially being able to automatically plug in features needs to > come first, although to implement it properly we probably need to > look at moving away from ECM, and using something like Merlin, or > a combined Merlin/Fortress container. Exactly. If you think about a Merlin/Fortress marriage you probably are at the pre Block level. Extend them to interconnect different block with the block: protocol and you'll be there. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
