Stefano's mini-talk at the GT2003 Hackathon.

Raw notes taken collaboratively during the talk.

Real Blocks - introduction by Stefano

The Naked Cocoon

Today Cocoon is seen as big servlet by users. With Blocks, you would install a basic Cocoon (core components + minimal 'hello world') and you'd plugin at runtime, the functionality you need.

Blocks vs. WAR files

Blocks could be seen as similar to WAR files, but will do more. The WAR file equivalent could be a first phase, but applications loaded from WAR files are isolated and cannot communicate or depend on each other, whereas Blocks are seen as collaborative (yet isolated) components.

What are blocks (dry definitions)

Blocks use cases

Challenges

Additional notes

Block extension: Wrap one block with another.

Block Extension:

I can say this block can have a contractual relationship, at runtime, with another block. Calls to base block are extended by (intercepted by) the extending block. If the extender does not handle, it falls back to the original, which can handle it, or pass it back to Cocoon itself.

Block Reuse:

I ask for a PDF block, but there are 3 implementations. The deployer asks, "which one would you like?". I choose one, the deployer goes off to download it, and hooks it up. Another Block asks for PDF. Cocoon 'knows' I am already using it, it can be used by the new Block without duplication.

How do we describe this behaviour? Not in a way that can be validatable

Use a weak typing (?): using a URI to locate blocks

You can switch blocks at runtime, test, and rollback if required

Will not directly expose public methods of enclosed components

Remaining issues

GT2003RealBlocks (last edited 2009-09-20 23:42:45 by localhost)