Stefano Mazzocchi wrote:
> What I would like to see is something like this: > > 1) src/block/*/block.xml > > that contains something as simple as > > <block name="a"> > <depends-on block="b"/> > <depends-on block="c"/> > </block> > > 2) this info used by cocoon at startup time (NOT COMPILE TIME!) to drive > the xconf imports. > > How hard can that be!?!
To make sure that we all are talking about he same I want to summarize my understanding of where we are now in our process of getting real blocks:
A block provides services that are exposed *explicitly* by
- pipelines - flows - components (Java objects)
Those services have to support inheritance and delegation.
A) Pipelines
------------
Every block has a root sitemap (specified in block.xml) that exposes all pipelines. The introduction of the block protocol (e.g. block://anotherblock/myPipeline) you can call the pipelines of other blocks. Note that this protocol is aware of inheritance of blocks.
Currently we have two kinds of visibility, visible only inside of Cocoon (internal-only="true") or visible everywhere. Probably we need more differentiation here so that we have
- public - inter-block - intra-bock
visibility.
B) Flows -------- Within your flowscripts you have access to
var x = cocoon.blocks.otherBlock.myFunction()
and this delegates to "otherBlock" that executes this function. At the end the return value is returned to the calling function. Note that myFunction can create its own continuations.
Here we had a rather long discussion (e.g. Stefano's usecase of super() calls) that ended with an excellent summary by Daniel (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110546513027583&w=2).
C) Components
-------------
The service manager of Cocoon has to be extended so that it gives access to components of other blocks. A lookup of
serviceManager.lookup("block:otherBlock:blockRole")will return a component.
block.xml
---------
... is the *central* configuration file of a block. It contains all dependencies of a block. Anything that needs this information _queries/uses_ block.xml!!!: the BlockManager, an XSLT that generates a gump project descriptor or an XSLT that generates an Ant build script for this block. We *must* keep information at one place.
How could a block.xml look like:
<block id="http://apache.org/cocoon/autentication-fw/1.0";>
<name>Autentication Framework</name> <author href="http://cocoon.apache.org";>Cocoon Community</author> <license href="http://www.apache.org/LICENSE-2.0/";> Apache Software License 2.0 </license>
<sitemap file="auth-root-sitemap.xmap"/> <components file="BLOCK-INF/block.xconf"/>
<requirements>
<requires
block="http://apache.org/cocoon/session-fw/1.0";
name="session"
/>
</requirements> <libraries>
<lib id="avalon-framework-api"/>
<lib id="avalon-framework-impl"/>
<lib id="excalibur-xmlutil"/>
<lib id="excalibur-pool"/>
<lib id="excalibur-sourceresolve"/>
</libraries></block>
As you can see, it contains general information about the block, information about the dependencies on other blocks and information on all library dependencies. (Note: Until we have the shielding classloader running, we have to explicitly name all dependencies on libraries because this is the only possibility not to end in JAR hell.)
wiring.xml
----------
Additionally to the block.xml descriptors that are related to a single block, we need a global wiring.xml that gives information about which blocks are installed, where they can be found and how they are configured.
Examples ... ------------
With the autentication block the services provided by the session block can be used:
MyComponent mc = (MyComponent)
serviceManager.lookup("block:session:myComponent");
<map:transform src="blocks:session://myPipeline"/>
function xyz() { var x = cocoon.blocks.session.myFlow(); }
To make this work we need explicit declarations in the session block which services are exposed.
The component is exposed in session-block/BLOCK-INF/block.xconf
<myComponent logger="myComponent"> <param>4711</param> </myCompnent>
The pipeline has to be exposed in the sitemap, either with a visibility of public or a inter-block:
<map:sitemap> ... <map:pipelines> <map:pipeline visibility="inter-block"> <map:match pattern="simplePipeline"> <map:genrate src="xyz.xml"/> <map:serialize type="xml"/> </map:match> </map:pipeline> </map:pipelines> </map:sitemap>
And the flow:
<map:sitemap>
<map:flow>
<map:script src="flow.js" inter-block="my*"/>
</map:flow>
</map:sitemap>
What's missing? ---------------
- implementation of the BlockManager that "knows" about the dependencies.
- pipelines: the blocks protocol that uses the BlockManager
- flows: make it possible to call functions of other blocks
- components: enhance te serviceManager so that it can access components
of other blocks.
And not to forget ...
* Block builder Of course the build system has to use the block.xml to build the block. A working prototyp can be found at http://svn.apache.org/repos/asf/cocoon/whiteboard/block-builder/
* Block deployment The deployment infrastructure has to use the informaton of block.xml too to ensure that all dependencies are resolved while deployment. A prototyp is available at http://svn.apache.org/repos/asf/cocoon/whiteboard/block-deployer/
PLEASE: Anybody working on a new build system or deployment, please consider
continueing my work!
See also http://wiki.apache.org/cocoon/BlockBuilder- o -
Trying to answer my own question (What have we reached so far?):
Again, I'm confident that we aren't that far away from making a big step forward to real blocks. If all the things above work, only Pier's kernel has to be integrated to get
- classloader shielding - the possibility to have "classloader interceptors" (e.g. to get a logging system where a logs are collected by one logging framework that is beneath the others)
and not to forget the integration of Torsten's compiling classloader :-)
If we all had time for a three-days-hackaton, things could get very far ... *sick*. Anybody interested in joining the party?
(I proposed this about 14 months ago and Stefano convinced me, that it would need more time to find out what we want. Looking at my summary above, I thing that we know it pretty well in the meantime.)
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}web(log): http://www.poetz.cc --------------------------------------------------------------------
