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 Thu, 22 Aug 2002 05:13:56 GMT
On Wed, 21 Aug 2002, Nicola Ken Barozzi wrote:

>
> Giacomo Pati wrote:
> > 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?
>
> The second you said.
>
> > 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.
>
> Blocks are not set in stone, and now Cocoon is in Alpha.

It doesn't have to do with "caved in stone" or development stage?

> Since these "modules" will become functional blocks, I want to go right
> away with the terminology.
>
> >>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?
>
> I never talked about this stuff, I just mean that *whatever* mechanism
> will be used, the dir layout of the blocks will not change.
> It's just a matter of defining these specifics, adding them to the build
> process.

Ok.

> >>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?
>
> To be honest, I do not have a particular architecture in mind, I was
> talking about the build.
>
> But if I have to say mine on blocks, I think that the easiest thing that
> can be done is to start very lightweight, and implement one feature at a
> time.

Why and which?

>
>     <>>>>>>>>>>>>>>>>>>>>><>>>>>>>>>>>>>>>>>>>>>>>
>
> The contract/interface of a block is the union of all the descriptions
> of what it exposes:
>
>  >>  1) Avalon component(s)
>
> Not exposed, but Cocoon must be able to merge the supplied xconf with
> the Cocoon one.

Merging is one way, a hierarchy of Containers/CM/SM the other.

> In the future we should separate them from cobs and have Cocoon work ala
> Merlin via dependency descriptors.

No, they are part of cobs.

> But if we buy in this too soon we would just loose time, without real gain.

Can you explain?

>
>  >>  2) Cocoon component(s)
>
> Cocoon components will be automatically available as declared in the
> root sitemap.xconf.

You think of a new config file (siteamp .xconf)? Cocoon components aren't
defined in sitemap.xmap but in cocoon.xconf. You are confusing me.

> Similar to what done with the Avalon ones.
>
>  >>  3) resources
>  >>  4) examples
>
> Simply an URI set of values for the files and the list of the sitemap
> snippets that can be called, with human-readable description of what
> these do.
>
>
> All this would make the system usable right away without big problems,
> refactoring or design discussions.
>
>

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