On Tue, Aug 20, 2002 at 04:13:35PM +0200, Giacomo Pati wrote:
> On Tue, 20 Aug 2002, 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.
>
> 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
Thanks for the reference, I'll have a look at it.
..<snip/>..
> > 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.
Yes.
> > 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.
*nod*.
So the skip:/adtd2html part actually defines part of the
block interface you were describing above.
You could have a 'gcSkip' and a 'mcSkip' that provides the 'skip'
interface and both implemntations would be considered
equal ?
> > 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?
Not in size but in intent, perhaps the word 'include' was misleading.
Essentially I see modules providing specific functionality outside
the core (libraries, generators, serializers), but not actually using
it, where as blocks use the functionality provided by the core and
whatever modules they need (along with any custom components they
may have).
ie. a module is something like a jsp.jar which includes all thats
necessary to use jsp's inside your cocoon app. A fop module
includes all that's necessary to use fop.
A block contains the actual application data (sitemap, stylesheets,
custom components, configuration, etc) that uses the features
provided by the core and these modules (and potentially other blocks)
When I said 'include' I mean't that the .cob could contain
actual module jar's itself if they weren't going to be used anywhere
else in the application (localizing and allowing blocks to use
different versions of the same library if needed).
Is that how you understand it too ?
> > 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.
Yes. Merlin/Fortress supports hierarchical containers which I think
fits the model well - each block could run inside its own container
(something like a BlockContainer) and communicate with other
containers via the block: protocol, etc.
Merlin already supports the dependancy, versioning and assembly
requirements blocks would have too.
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]
