cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: New "module" terminology: WAS: Extending the build system for modules
Date Mon, 19 Aug 2002 21:28:03 GMT

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".

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.

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.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message