cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Real blocks: some thoughts and questions
Date Sat, 13 Sep 2003 14:05:44 GMT

On Thursday, Sep 11, 2003, at 20:11 Europe/Rome, 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.

yes

> 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.

I'll try to fill the gaps.

>
>                              =====
>
> The main features that cocoon blocks have that are not in pure 
> packaging
> solutions like war's are:
> * block dependencies, including polymorphism
> * block inheritence
>
> The first I quite understand, the second not so much.

ok

> 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

correct

> 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

yes, this is forbidden because it would create major issues with 
reloading and hot deployment. going thru the avalon machinery helps 
with this and keeps things sane. [note this is the same paradigm used 
in EJB]

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

yes, we decided not to do this, expecially since it would have required 
two different internal-block URI spaces, one for the URLs provided by 
the sitemap and one of the one provided by the block. moreover, given 
the caching facilities we have, using readers to provide a transparent 
one-2-one mapping is just three sitemap lines away, would it be needed.

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

these are hidden on purpose since they very likely don't make sense 
alone (means: without the sitemap)

> One exception is that the yet-to-come virtual sitemap components (or
> whatever they're called) could be used across blocks.

yes, since they will be much like other avalon 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.

block inheritance started as a resource thing, that's right, but later 
evolved into a general URL thing.

In short, when block A extends block B, the sitemap A is called and, if 
no pipeline is matched, instead of returning a 404, the sitemap A is 
called. Only if sitemap A doesn't match, the 404 is triggered.

it's as simple as that.

The reason for this is that I can "overload" some of the URL present in 
sitemap A without having to modify it. Mostly useful in skins and the 
like or in any environments where users of blocks might want to modify 
a few things of the original block, but without having to create their 
own version.

just like in OOP, extending one object allows one to keep in synch with 
new versions of the extended objects without cut/paste code.

the same will happen for blocks: if you change your logo of our skin, 
and we improve our skin, the improvements will be automatically 
inherited and you wouldn't have to do anything.

in short terms, the above is sort of an interception mechanism for 
sitemaps, just very specific, because I don't think we need anything 
else for now.

> 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:

no, well, you have to declare your component as before

  <map:serializers>
   <map:serializer name="fo2pdf" class="my.package.MyClass"/>
  </map:serializer>

the component manager handling the block that contains this sitemap 
will ask the block deployer for the proper wirings and will find the 
appropriate instance. which will be normally referenced as:

> <map:serialize type="fo2pdf"/>
>
> Now how will the component manager know which of the depended blocks to
> ask for this component? Check them one by one?

yes. note that since blocks have to "declare" the components they 
provide, the deployer manager can check for collisions at deployment 
time and prevent sibling blocks to have shared components.

> 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.

hope I got your point right.

> 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?

I thought about this, but I don't think it's needed. even if, if we 
want to add something like this, that is:

  <map:serializer name="fo2pdf" class="block:fop:my.package.MyClass"/>

I wouldn't be against it. Just I don't think it's required and 
introduces a semantics of component role lookup that hasn't been seen 
before (and might collide with the avalon component managers we use in 
the future, but I'm not an expert in this field anymore)

> 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.

yes, it will. for back compatibility with cocoon 2.1, the blocks will 
be "mounted" at some point in the main cocoon sitemap. either 
implicitly at the very beginning, or explicitly with a new 
<map:mount-blocks/> tag.

either one is fine for me.

> * 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.

no, the components are declared in the sitemap that uses them, not in 
the sitemap of the block that exposes them.

hope this helps.

--
Stefano.


Mime
View raw message