cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinhard_po...@yahoo.de>
Subject Real blocks - What have we reached so far?
Date Sun, 13 Feb 2005 15:29:33 GMT
[Some months ago I started my work on a block builder and a block deployer. As 
we agreed on releasing 2.2 without support for real blocks, I changed my 
priorities in favour of a new documentation system.]

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


Mime
View raw message