Carsten Ziegeler wrote:
Sylvain Wallez wrote:Carsten:
IMHO, this example goes strongly against the benefits that blocks want to bring. The functionnality brought by the 'skin' block is... skinning. It's not an XSL stylesheet at a particular location. What if someone has written the killer skin for his site, but this skin requires a multi-stage pipeline that cannot be represented by a single stylesheet ?
The contract of a block should be services identified by their URI, and not files at well-known locations (even if these 'files' are in fact produced by a pipeline).
So what about something like :
...
</map:aggregate>
<map:call resource="block:skin:/site2xhtml"/>
</map:match>
This call "jumps" to a service provided by the block and its URI is part of the block's contract. We don't care (because we don't have to) if the service is implemented by an XSL or by the next-generation transformer.
What the "jump" does is feed a pipeline in the block with the result of the current pipeline. The whole pipeline is terminated in the called block.
But just as a pipeline can serialize or not depending on if it's an internal request or not (see SitemapSource), the same service could be used as a transformation. We could then write something like :
...
</map:aggregate>
<map:transform type="pipeline" src="block:skin:/site2xhtml"/>
<map:transform type="urlencoder"/>
<map:serialize/>
</map:match>
By considering blocks as pipeline services, we really achieve true polymorphism for blocks, because we totally abstract the way their contracts are implemented.
I absolutely agree with this, but I have two comments: a) I think a block should also be able to expose resources directly, e.g. images.
Do you think it would be reasonable for access to a resource to be expressed as a service. I.e. the client goes though an interface exposed as a service to access the resource. This present the benefit that the block (as the resource repository) does not need to be exposed to the client. It also means that we are always dealing with the same conceptual service access model.
Cheers, Steve.
b) Is it possible to unify map:call and map:transform? Does it make sense?
Or is it better to have a different notation to emphasize the different
usage?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
