Giacomo Pati wrote:
> On Wed, 21 Aug 2002, Nicola Ken Barozzi wrote:
>
>
>>Giacomo Pati wrote:
>>
>>>On Mon, 19 Aug 2002, Nicola Ken Barozzi wrote:
...
>>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.
Yes. "Merge" conceptually.
Though maybe in the beginning we can make a quick working system out of
simple merging.
I try to find the easiest solution ATM to get it working quick.
>>In the future we should separate them from cobs and have Cocoon work ala
>>Merlin via dependency descriptors.
>
> No, they are part of cobs.
IMHO no.
Avalon components can be used in other containers other than Cocoon, and
so must be used as-is.
The cob in the future should define he dependency in the descriptor, but
not /necessarily/ contain the Avalon component itself.
It will still be able to do contain them though, if they are tied to the
Cocoon component ala couplet.
>>But if we buy in this too soon we would just loose time, without real gain.
>
> Can you explain?
If we try to build complete cob support from the start we will be doing
a lot of work without knowing the impact, and use a lot of time and
effort without knowing the outcome.
I prefer baby-steps if possible, so that we can quickly have a working
system, gain feedback, make it better, etc.
>> >> 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.
<map:components>
^^^^^^^^^^^^^^^^^
<!--
All pipelines consist at least of two components: ...
-->
<map:generators default="file">
<map:generator label="content,data" .../>
...
>>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]
