cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: New "module" terminology: WAS: Extending the build system for modules
Date Tue, 20 Aug 2002 13:48:58 GMT
On Mon, 19 Aug 2002, Nicola Ken Barozzi wrote:

>
> 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'm too ;-)
>
> Ok, since I am the one going to make the change to the CVS, and since
> with lazy consensus Carsten's who-committs-chooses-the-name, I therefore
> hint that I might commit the change in a directory called "blocks".

Please wait a minute. Are you implementing a Cocoon Block infrastructure
as proposed by Stefano or are you modularizing the build process similar
to avalon-excalibur?

Don't use the block terminology for something still in the mind of
Cocooners like Stefano, me and probably others for something that
doesn't fullfill the expectation.

> Why?
>
> Simple.
> A "module" will soon be a directory that contains
>   1) Avalon component(s)
>   2) Cocoon component(s)
>   3) resources
>   4) examples
>   5) configuration info
>
> Example of a jsp module
>
>   1) org.apache.cocoon.components.jsp.*
>   2) org.apache.cocoon.generation.JspGenerator
>   3) -
>   4) jsp samples
>   6) jsp.xconf
>
> Example of a jsp.cob
>
>   1) org.apache.cocoon.components.jsp.*
>   2) org.apache.cocoon.generation.JspGenerator
>   3) -
>   4) jsp samples
>   6) jsp.xconf
>   7) cocoon.xcob (cob descriptor)
>
> As you see, the only difference is the existence of a descriptor and of
> a mechanism for Cocoon to plugin the cob automagically, instead of
> during the build.

Ok, can you elaborate more on this mechanism of deployment/plugin?  Is
there an abstraction possible for Block interfaces and Block
implementations so that Cocoon (or a user) is able to choose between
different implementations of a Cocoon Block Interface?
Does this mechanism support hot deployment of a .cob over the wire?

> So I see this as a first step to blocks.
> Once they are refactored in their directory it will be easier to make
> the blocks work.

Well, this is easily said but could you tell us more about the
architecture/design you have in mind?

Giacomo


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


Mime
View raw message