cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: [RT] Implementing Cocoon Blocks
Date Fri, 29 Aug 2003 12:16:41 GMT
Andreas Hochsteger wrote:
> 
> Geoff Howard wrote:
> 
> *snip many good suggestions from Geoff and Stefano*
> 
>> For sake of discussion, I recorded a wire-id instead of the location. 
>> Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?
> 
>> I also considered recording the wire-id instead of the uri for 
>> connections between blocks - what are the arguments for each?
> 
> Where does the wire-id come from?
> Is it an ID which is dynamically created at deployment time or has that 
> to be unique among all possible blocks on the net (would be hard to 
> manage)?

This was mimicked (as was everything else) from Stefano's original 
proposal, so I can't answer with authority... but I've assumed this was 
autogenerated by the block-deploy mechanism (Block Manager).  So, not 
globally unique, just unique within a given wiring.xml and therefore a 
given Cocoon instance.

>> <connection> was out of the blue using the wiring metaphore.  Other 
>> options?  Free association: connect, attach, solder, wire, use ...
> 
> Do the terms 'connection' and 'wire' represent the block dependencies?
> If so, why not just call them so?
> I think it's much easier to understand IMHO.
> Wiring is perceived as complicated at least in my mind although I've 
> learned how to create electronic circiuts ;-)

Again, only my understanding:
No, this is the actual connections made between the dependencies 
declared in the block's config declarations.  There is another schema 
for that which is yet to come which describes dependencies.  The wiring 
as I understand it is the _resolved_ dependencies which are figured out 
by the block manager/deploy admin at deploy time.

What isn't yet represented but maybe should be is what happens if I 
deploy a block for which some dependencies are met, but not all (yet). 
How to represent that a block is in the system, but not yet active 
because it is still waiting for a block to provide a missing dependency.
In my head I'm thinking that it will be possible to have interconnected 
dependencies which have to go in place all at once.  Can that 
possibility be logically eliminated?

>> Is it wise to limit configurations to name-value pairs, or should that 
>> allow arbitrary foreign xml markup?
> 
> Arbitrary foreign XML markup might not be a mistake IMO.

Can anyone think of use cases?

Geoff


Mime
View raw message