cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: New "module" terminology: WAS: Extending the build system for modules
Date Tue, 20 Aug 2002 09:12:28 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message