You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by st...@outerthought.org on 2003/09/27 14:00:04 UTC
[WIKI-UPDATE] BlocksDefinition Sat Sep 27 14:00:03 2003
Page: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition , version: 20 on Sat Sep 27 11:30:26 2003 by 67.21.159.90
+ ''What about "implements"?''
+
- blocks will contain configurations that is written at block-release
? ^ --------
+ Blocks will contain configurations written at block-release
? ^
- time but there are information that are deployment dependent. The block
? ^^^^^^^^ ^^^^^^^^
+ time but some information is deployment dependent. The block
? ^^^ ^^
- deployment descriptor contains a list of those configurations that are
? ^^^^^^^ ^^^
+ deployment descriptor contains a list of those parameters that are
? ^^ ++ ^^
- Since these configurations will rather be context-dependent tokens,
? ---
+ Since these configurations will be rather context-dependent tokens,
? +++
- <properties>
+ {{{ <properties>
? +++
- </properties>
+ </properties>}}}
? +++
+
+ ''This needs to be synced with the block.xml discussion''
+ {{{...
-
- ...
- ...
+ ...}}}
+ * pipelines ??
- Blocks that depend on this block might use the component role (as they normally did with block-less cocoon) and the component manager will load the appropriate component (everthing is done by the component manager and the block manager thru block.xml and wiring information)
? ------ ^^ ^
+ Blocks that depend on this block use the component role (as they normally did with block-less cocoon) and the component manager will load the appropriate component. Everything is done by the component manager and the block manager thru block.xml and wiring information.
? + ^^ + ^
+
+ ''What happens with role name conflicts?''
- Following IoC practices, there isn't (andthere should not be) a way for a block to directly access another block.
+ Following IoC practices, there isn't (and there should not be) a way for a block to directly access another block.
? +
- Blocks access the blocks they depend on thru a block-specific protocols that is able to dereference the block instances thru wiring.
+ Blocks access the blocks they depend on through a block-specific protocols that is able to dereference the block instances thru wiring.
? + ++
- Not only a sitemap needs to connect to the resources contained in the
? -
+ Not only does a sitemap need to connect to the resources contained in the
? +++++
- blocks on which the block depends on, but the resulting pages as well.
? ----- --- --------
+ blocks it depends on, but the resulting pages as well.