cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <craft...@fztig938.bank.dresdner.net>
Subject Re: New "module" terminology: WAS: Extending the build system for modules
Date Tue, 20 Aug 2002 09:02:40 GMT
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.
	
	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.
	
	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.
	
	My 2c AUS. :)
	
	Cheers,
	
	Marcus
	
	

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message