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.
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.
>>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.
<>>>>>>>>>>>>>>>>>>>>><>>>>>>>>>>>>>>>>>>>>>>>
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.
In the future we should separate them from cobs and have Cocoon work ala
Merlin via dependency descriptors.
But if we buy in this too soon we would just loose time, without real gain.
>> 2) Cocoon component(s)
Cocoon components will be automatically available as declared in the
root sitemap.xconf.
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.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
