Hi, ............. .............
> This contract explicitly indicates: > > 1) web resources exposed by the block (for example files accessible > from other blocks) > 2) service components exposed by the block (for example avalon > components or sitemap components) I don't want to start another hot-headed discussion, but IMO Phoenix provides already a framework for service components. Lifecycle management, logging, thread pools, class-loading management, and service assembly/interdependencies can be use for many parts of Cocoon. Cocoon does a good job at managing fine grained components (sitemap components), but fails in managing coarse grained components (service components). Example of services that can be imediatelly implemented as Phoenix blocks are components like: Server.java (hsql db) JSPEngine.java RendererFactory.java LuceneCocoonIndexer.java LuceneCocoonSearcher.java TranscoderFactory.java XSLTProcessor.java Store.java StoreJanitor.java .... > > Each block contains a descriptor file (located in > /BLOCK-INF/block.xinfo) which indicates: > > 1) information about the block (author, version, original location, > license and all that other block metadata) > > 2) behavioral contract that the block implements (along with > information on mappings between the contract and this block's > implementation) > > 3) dependencies: this is a list of zero or more 'block contracts' upon > which the block depends. Maybe I'm missing the point, but shouldn't be there another packaging level where all blocks are bundled together with roles, sitemap, and flowmap descriptors? > > -- o -- > > The resources exposed by blocks are accessed using a URI-compatible > protocol description of the form: > > block:[role]://path/resource > > where > > block: -> identifies the protocol > [role] -> identifies the block in the current context and it's a short > identifier that maps to the fully-qualifying URI that identifies the > block contract. > > For example, suppose we have something like this: > > <map:transform src="block:skin://xslt/document2html.xslt"> > > the block role 'skin' must be translated to a fully qualifying URI (much > similar to the prefix -> URI translation that happens for XML > namespaces). > > This is done by adding the following semantics to the sitemap: > > <map:blocks> > <map:block role="skin" > uri="http://apache.org/cocoon/blocks/skin/2.1"/> > </map:blocks> > > After this translation is performed, the 'block:' protocol handler will > have to identifiy the resource and retrieve it from the block archive > (which can be extracted or left compressed, this should not change > behavior since the blocks are not allowed to write in their own > addressing space directly). > > This mapping is performed by the block deployer, which has the > information on how to map this URI to the block that was installed to > operate that contract for the requesting block. > > This futher decoupling is the key to the polymorphic behavior of blocks: > in fact, the block "role" identifies a contract, not an actual > implementation and it's therefore entirely possible to: > > a) have different implementations of the same block associated to > different blocks, so, for example, two different blocks might require a > 'skin' role, but each of them might have associated different > implementations of that role. Do you mean here to replace ComponentManager/Selector with the CM interface discussed for future Excalibur release CM.select(String role, Object query) where, in this case, query would be the URL? > > b) share the same implementation between different blocks. > > c) hot-deploy/hot-update a block implementation simply by changing the > last mapping translation. > > -- o -- > > The logic components exposed by the blocks are located exactly as > before, using fully qualified dot-notation for java classes. All > translation and mapping will be automatically performed by the > classloaders. > > So, for example, if Block A does > > <map:generator type="mygen" class="com.mystuff.whatever.Generator"/> > > the classloader responsible for Block A will look for that class in the > /BLOCK-INF/lib or /BLOCK-INF/classes directories and included jar > archives of the blocks on which this Block A depends on. > > -- o -- > > Here I describe a potential use of a block-based cocoon system: > > 1) let us suppose that Cocoon is already installed in a servlet > container and up and running. > > 2) let us suppose that we have a tool that implements block > management/deployment on top of Cocoon [how this is implemented is not > important for our current needs] > > 3) the user has three ways to install new blocks: > > - provide the block manager with a URI where the block archive is > located on the web > > - have the block manager discover and locate a block repository, > which will be a web service that will interact with the block manager > and list information on new blocks and all that (sort of apt-get) > > - provide the block manager with a 'block deployment descriptor' > which contains an 'installable' and complete dependency set of blocks > that implement a given web application. (this is to ease installation) > > 4) once the user has choosen what block/s to install, the block manager > downloads it/them from the internet and reads its metadata to find out > eventual dependencies. > > 5) for each dependency, the block manager scans the registry of > currently installed blocks in the system. If a block that implements the > dependent contract is already installed, the user is ask to confirm its > use, otherwise, the block manager will look in the block repositories to > download the appropriate block and will ask the user to choose between a > list of compatible implementations of that role. This things are currently implemented in Phoenix, but in kernel space. I agree that these features should be implemented in application space, having a Cocoon specific implementation but service oriented. > > In case of deployment descriptors, the block manager can be asked to > install the system without performing checkings (but these are > implementation details) ...... ...... > At the same time, this description format is very well going to be so > complex that WSDL will look like piece of cake and I'm scared about > this.... on the other hand, it might enable things like form validation > and so on automatic and rather painless. I know that I am biased towards using Phoenix as a framework to develop Cocoon using a service-oriented approach, but I think its a good way to manage the increasingly growing Cocoon code base. Mircea --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
