cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [RT] Finishing the first phase of block design
Date Wed, 08 Oct 2003 12:13:41 GMT
Andreas Hochsteger wrote:
> Geoff Howard wrote:
>> Exposing Resources
>> ------------------
>> I'm adding this because my brain is still a little unsure about this. 
>> So far, we've said that file resources (an xsl for example)
>> 1) need to be exposed via a sitemap pipeline, even if only by a reader
>> 2) are not anywhere declared explicitly (except in the pipeline of 
>> course)
>> 3) are not distinguised from resources meant to be private by any 
>> formal semantics, though this information could be conveyed 
>> human-to-human in any block docs (blocs? blockumentation? ;) ).
>> Here are my oustanding questions:
>> - Will we regret requiring the overhead of pipeline setup (runtime I 
>> mean) for blocks which expose a great deal of otherwise static resources?
>> - Not found resources will have to go through every pipeline to 
>> determine that it's not found.  With fallback behavior due to 
>> polymorphism this gets worse.
>> - Will not explicitly declaring which resources are meant to be public 
>> cause trouble for block implementors and extenders?
> If a block provides resources (e.g. an XSL file) it also implicitely 
> provides a contract for the use of this XSL file. This would be an XML 
> document conforming to a certain schema (no matter if xsd, dtd, rng, ...).
> Until now I've not understood how you can describe this contract. Is it 
> something we want to take care of now, or do we extend the explicit 
> contracts, when we have some experiences with blocks to know how to deal 
> with this issue.
> This can also affect other resources too:
> If you provide a skin block which another block extends, how can you 
> make sure, that the logo has the size 80x80 pixels?
> There are surely many areas where it might make sense to explicitely 
> describe those contracts, but I fail to see, if this is planned nor if 
> we should take care about this now.

I think it's not planned now or in future to explicitly describe these 
_in machine readable form_ (this does not preclude a document targeted 
at humans to describe what must be done or not done).  The idea is that 
there are so many different shades of "contracts" that they could never
really be described explicitly.  By the way, this is almost a complete 
quote of what Stefano said at one point.  I'm not claiming to be an 
authority on blocks - just regurgitating what I've taken in.

What I'm musing about though is not qualitatively describing the 
behavior or resource, but just naming it or otherwise labeling it 
explicitly as exposed or not exposed.  One option is to add it to the 
block.xml but I think this would be tedious if we also require a 
pipeline setup.

However, Stefan Michels' proposal about declaring access modifiers on 
sitemap elements (he was referring to components but I'm specifically 
keying in on pipeline definitions) may be just the ticket: simple, 
declarative and clear.  By the way, it is sort of analogous to the 
meta-info stuff at Avalon.  The deploy process for a block may find it 
useful to assemble and organize information on which pipeline resources 
are publicly available, but that can be decided at implementation time.


By the way, I forgot to add one more question on my list of musings:

- Would even "internal-only" pipelines be protected as things stand now 
in the design?


View raw message