Marcus Crafter wrote: > > > 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. > > 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. > Very good analysis! So, I can only repeat, modules and blocks are not the same and we should have different names for both.
> Blocks can have dependancies and can communiate with other > blocks via > sessions, etc, 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. > > 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. > ;) Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
