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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
