cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: Real blocks: some thoughts and questions
Date Fri, 12 Sep 2003 03:23:49 GMT
I'm thinking aloud -- not claiming I've got the right answers...

Bruno Dumon wrote:

> I've been reading through the most recent block related threads: Cocoon
> Blocks 1.1 [1] and Implementing Cocoon Blocks [2]. These two documents
> pretty much complement each other, the first mostly focussing on the
> blocks itself (not just a package but also inheritence and
> polymorphism), the second one more focussing on the block manager and
> block deployer. 
> 
> What I've written below are partly summaries and partly questions. I'm
> posting it here, if anyone can offer clarifications on some of this than
> that would be great, and otherwise it'll serve as input for the
> hackaton.
> 
>                              =====
> 
> The main features that cocoon blocks have that are not in pure packaging
> solutions like war's are:
> * block dependencies, including polymorphism
> * block inheritence

I'd add what seems to be generalized block services.  A block is 
dependent on another block's service, so maybe they just go hand in hand 
with dependencies.  The definition of exactly what that service is seems 
very general.  In some cases, a file resource.  In some a true 
component.  In come, pipelines or pipeline fragments.  Maybe more.

> The first I quite understand, the second not so much.
> 
> Dependencies between blocks
> ---------------------------
> 
> If I got it right, the only dependencies we got between block are:
>  - a block can use a component from another block (either a sitemap
> component or a generic Avalon component)
>  - a block can call a pipeline described in the sitemap of another
> block, using the block: protocol

See above -- I'm not sure this is all there is.

> Some things that would thus explicitely not be possible (at this point)
> are:
>  - classloading dependencies: a block cannot depend on classes or jars
> inside another block

I think that's right - no direct dependency on them.

>  - resource dependencies: one block cannot directly access files (such
> as XSL's) in other blocks

Not sure if that's true or not.

>  - other sitemap dependencies: using flows, views or resources from a
> sitemap in another block.

I don't know.

> One exception is that the yet-to-come virtual sitemap components (or
> whatever they're called) could be used across blocks.
> 
> Extending blocks (block inheritence)
> ------------------------------------
> Reading the Cocoon Blocks 1.1 proposal [1] makes me think that block
> inheritance is a file-based thing, i.e. files not found in the extending
> block are taken from the extended block. Though in some other post in
> the discussion following on it, Stefano writes:
> 
> "Here, when a sitemap *extends* another one, it's means of falling back:
> the two sitemaps are appended and if no matching happens in the first
> one, it falls back on the extended one."
> 
> Which implies that the extending is more dynamic, i.e. there exist two
> sitemap interpreters at runtime etc.
> 
> Other than that I couldn't find much information on block inheritence,
> so if anyone can shed more light on it, that would be very welcome.

I interpret it to be service-based.  A block exposes services which are 
interited/overridden by extending blocks.

> Component lookup
> ----------------
> I'm wondering how component lookup will work. For example, suppose I
> have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll
> make my block depend on the fop blok (or the more generic
> cob:apache.org/cocoon/fo2pdf role). Now how will using the serializer
> work? I assume I won't have to declare it in the map:components section
> of my sitemap anymore, since the instances of that serializer will be
> managed by the component manager of the fop block. So I'll just be able
> to write somewhere:
> 
> <map:serialize type="fo2pdf"/>

I think you'd have to use the block: protocol as you mention below?

> Now how will the component manager know which of the depended blocks to
> ask for this component? Check them one by one? Up to now all component
> managers are in a parent-child relationship, but blocks will need to use
> components from sibling blocks. Hope my explanation is clear enough.

The block descriptor (block.xml, yet to be fleshed out) declares what a 
block "exposes".  The deploy process wires the dependencies of one block 
to the exposed services of another.  What your example brings up is the 
question: how does this work when services/resources are called from 
outside a block, as in a plain sitemap.

> Hmm, now that I think of it, with the block: protocol there is explicit
> block addressing: block:dependencyname:/something. Probably we'll have
> something similar for component lookups?

That may answer the above question.

> Other various stuff
> -------------------
> 
> * I assume the block's sitemaps won't have a parent sitemap, i.e. the
> Cocoon root sitemap will not be the parent sitemap for block sitemaps.

I think that's right.  The block mount-points get first crack at 
requests.  They're more like super-sitemaps (not parents because the 
root sitemap won't inherit from them).

> * Currently sitemap components are managed by a sitemap component
> manager. I assume that with blocks, sitemap components will also have to
> be mangeable by the "main" block component managers? I.e. the fop block
> won't have to include a sitemap simply to declare the the fo2pdf
> serializer.

Yes, I'd assume that's the case.

Now, maybe someone can come along and fix my guesses.

Geoff


Mime
View raw message