You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/06/04 20:38:08 UTC
[Ann/RFC] "Sitemap Blocks"
I have added a first, hopefully working, version of the sitemap aspect
of real blocks to the trunk. No functionality to get components (not
even VPCs) yet from the blocks.
Examples can be found in:
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/
the implementation is supposed to follow
http://wiki.apache.org/cocoon/Blocks and the result of various mail list
discussions (although I can have missed things).
Use
===
FS layout
---------
A block has the file system layout
[cocoon block] [DIR]
|
+-- COB-INF [DIR]
+-- block.xml
+-- classes [DIR]
+-- lib [DIR]
according to http://wiki.apache.org/cocoon/BlocksFSLayout. Where
block.xml is described in http://wiki.apache.org/cocoon/BlocksCob.
[cocoon block] is like an ordinary Cocoon top level directory and
typically contains a main sitemap, files and sub directories.
Configuration
-------------
block.xml describe where the main sitemap is and all component
configurations are done from the main sitemap. Either directly in
map:components or indirectly through an include
http://svn.apache.org/repos/asf/cocoon/trunk/src/webapp/WEB-INF/cocoon.xconf.
The code in COB-INF/[classes|lib] can be found throgh the local
classloader
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111032234204889&w=2.
The deployment configuration including URLs to the blocks is done in
wiring.xml, http://wiki.apache.org/cocoon/BlocksWiring. Schemas for
wiring.xml and block.xml can be found in
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/schema/. Currently no
deployment tool is integrated so one have to write wiring.xml by hand.
The super block of a block is identified by
/wiring/block/connections/connection/@name='super', see
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/wiring.xml?view=markup
for an example.
The wiring file is used by the BlocksManager to set up all the blocks.
The BlocksManager is configured to point to the wiring.xml:
<component role="org.apache.cocoon.components.blocks.BlocksManager"
class="org.apache.cocoon.components.blocks.BlocksManager"
file="wiring.xml"/>
All access to blocks goes through the BlocksManager.
blocks: protocol
----------------
The blocks mount paths from deployment should in principle be used
before the main sitemap in the (main) webapp is called. But at this
point I didin't want to touch the core classes e.g. o.a.c.Cocoon or let
any core components depend on the block infrastrucuture. Therefore I
instead created a blocks: protocol that can be used in the main sitemap
to connect to the blocks system:
<map:match pattern="**">
<map:read src="blocks:/{1}"/>
</map:match>
block: protocol
---------------
The block: protocol, (http://wiki.apache.org/cocoon/BlocksDefinition and
http://wiki.apache.org/cocoon/BlocksDefinition) the blocks version of
the cocoon: protocol,
block:/test
will call the pipeline with URI test in the root sitemap of the current
block.
block:./test
will call the pipeline with URI test in the current sitemap of the
current block. In both cases block inheritance and polymorphism are
respected (take a look at
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test3/
for examples). The reason for not using "://" and ":/" for absolute and
relative addressing as for the cocoon: protocol is that it doesn't
follow the http://www.ietf.org/rfc/rfc3986.txt, see
http://www.betaversion.org/~pier/wiki/display/pier/Cocoon+and+URIs for
Pier's rant about it.
block:foo:/test
will call the pipeline with URI /test in the block. The extended block
can be explicitly called by,
block:super:/test
block-property: module
----------------------
A block can have a number of properties that can be given default values
in block.xml and deployment values in wiring.xml (see examples in
test3/). The value of a property in the current block can be accessed
with an input-module,
{block-property:foo}
There is no access to properties in other blocks. The blocks properties
can be used for things like db URLs and should IMO be block private.
block-path: module
------------------
A block URI block:foo:/bar where the foo block is mounted at /test can
be "absoultized" to /test/bar by using the block-path input module,
{block-path:foo:/bar}
see example in
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test1/sub/.
This module can be used together with the LinkRewriterTransformer
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html
from Forrest fame to creta the block link rewriting behaviour described
in the end of http://wiki.apache.org/cocoon/BlocksDefinition.
Implementation
==============
BlocksManager
-------------
o.a.c.components.blocks.BlocksManager is the "root" class of the blocks
frame work (it is a singleton). It reads the wiring.xml and configure
and creates all the blocks. It implements o.a.c.Process and take care of
requests to mounted blocks. The policy for mounted blocks is that the
most specific mountpath is used if several blocks mount points matches
the URI. I.e. for the request /foo/bar/blaha where block A: is mounted
at /foo and B: at /foo/bar, the request will go to block B:. The current
algorithm isn't that efficient.
All access between blocks are done through the BlocksManager and it also
takes part in absolutizing block: URIs.
The BlocksManager takes care of the same things as o.a.c.Cocoon, but in
the block context. The current implementation doesn't contain all the
sofistication of o.a.c.Cocoon yet. A later question is if we should
merge Cocoon and BlocksManager or if we should make it configurable
whether it is the main sitemap (through Cocoon) or the wiring.xml
(through BlocksManager), that is the "root" or keep it as is.
BlockManager
------------
The BlockManagers is created and configured by the BlocksManager and
represents a block. All the blocks communiciation with the rest of the
system is shielded by its BlockManager (well as there isn't any
classloader isolation yet the shielding is limited), which in turn talks
with the other blocks through BlocksManager. The BlockManager has an own
ServiceManager that gets some minimal parent manager that is configured
by
resource://org/apache/cocoon/components/blocks/core-components.xconf".
As mentioned above the local service manager can be extended with a
sitemap defined class path, it would be nice to do this implicitly for
COB-INF/[classes|lib].
The BlockManager also reads the block.xml and start a tree processor
based on the local sitemap. It implements Processor.
It contains and manages the block properties and take care of some part
of the block URI resolution.
At a later point I think that we should refactor the BlockManager so
that there can be several implementations. In this way (given
classloader shielding) one could maybe run several versions of Cocoon in
the same "blocks container".
Block
-----
o.a.c.components.blocks.Block is an interface that the BlockManager
implements and that is supposed to be used when the BlockManagrer is
used by other components. It need some more thinking.
BlockEnvironmentHelper
----------------------
o.a.c.environment.internal.BlockEnvironmentHelper extendes the
EnvironmentHelper with the static method Block getCurrentBlock(). The
BlocksManager takes care about always puting the currently executing
Block at the top of the Processor stack so that it an be found with
getCurrentBlock. Take a look at
boolean BlocksManager.process(String blockId, Environment
environment, boolean superCall)
This is the, somewhat subtle, main mechanism for polymorphism. Each time
a new block is entered through the block: or blocks: protocol, it is
done through the process methods of the BlocksManager. When a new block
is entered it is pushed at the processor stack. But when a block
delegates to its super block, the super block is not pushed. This means
that all block:/ and block:./lookups in the super block (and its super
blocks in turn) will be done through the block manager of the called
block. To make this work for relative block lookup, block:./ it is not
done by calling the current TreeProcessor as in the cocoon: protocol,
that would break polymirohism for relative URIs. Instead the relative
URIs are first "absolutized" and the used through the current block manager.
I made it an own class only to keep EnvironmentHelper indenpendent of
the blocks framework. At a later point they should probably be merged.
<OT>Or even better be replaced by a official execution stack with
current manager, context, logger, block, processor, object model and
sitemap params. With such a thing we could get rid of the use of
Servicable, Context, Logger and some other stuff and use about any
container internaly</OT>
BlocksSource
------------
o.a.c.components.source.impl.BlocksSource, implements the blocks:
protocol. Delegates to mounted blocks through the BlocksManager, should
be made caching and probably XMLizable.
BlockSource
-----------
o.a.c.components.source.impl.BlockSource, implements the block:
protocol. Uses the current block from the BlockEnvironmentHelper and
delegates the URI parsing and processing to the BlockManager. Should
also be made caching and XMLizable.
BlockPropertyModule
-------------------
o.a.c.components.modules.input.BlockPropertyModule, implements the
block-property module. It is rather straight forward and delegates the
work to the current block manager. What lacks is a POJO friendly
getProperties() method in the BlockManager, and a clear idea about which
default values and deployment values that should take precedence in the
case of block extension, take a look at the property handling part of
BlockManager.initialize().
BlockPathModule
---------------
o.a.c.components.modules.input.BlockPathModule, implements the
block-path module. It is rather straight forward and delegates the work
to the current block manager.
State
=====
It is obviosly not tested that much yet. The interfaces and
implementation needs community involvement.
--- o0o ---
WDYT?
/Daniel
Re: [Ann/RFC] "Sitemap Blocks"
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
>
>>>Give me a 3 lines description of where to start looking and I'll get
>>>going.
>>
>>A good starting point is the BlocksManager and sitemap component
>>configurations in the test cases:
>>src/test/org/apache/cocoon/test/components/blocks/BlocksManagerTestCase.xconf.
>
> all right, I'll start from there... is there any I have to modify in
> cocoon to make the block manager work or it's already integrated?
It is allready integrated.
You can run the tests with:
$ ./build.sh core-junit-test
-Djunit.testcase=org.apache.cocoon.test.components.blocks.BlocksManagerTestCase
-Djunit.test.loglevel=1
All the tests are supposed to pass, but creates an irritating amount of
stack traces from the ComponentLocator.
> (sorry for being clueless, but I've not been following the code very
> much lately)
No problem, just ask if you run into any troubles or if the code is unclear.
/Daniel
Re: [Ann/RFC] "Sitemap Blocks"
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
>> Give me a 3 lines description of where to start looking and I'll get
>> going.
>
> A good starting point is the BlocksManager and sitemap component
> configurations in the test cases:
> src/test/org/apache/cocoon/test/components/blocks/BlocksManagerTestCase.xconf.
all right, I'll start from there... is there any I have to modify in
cocoon to make the block manager work or it's already integrated?
(sorry for being clueless, but I've not been following the code very
much lately)
--
Stefano.
Re: [Ann/RFC] "Sitemap Blocks"
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
<snip/>
>>Now, to continue the work on the sitemap aspect of blocks we really need
>>to apply it in a non trivial application. By doing that we will get more
>>experience of the involved concepts. It would also make it easier for
>>the rest of the community to see what the sitemap aspect of blocks can
>>be used for. There seem to be a large community interest in the
>>component aspect of blocks, but not yet in the sitemap aspect. Actually
>>using it in a real use case would also increase my and others motivation
>>to polish the implementation.
>>
>>I think that the Linotype would make an excelent use case for
>>introducing the current block mechanism in. Are you interested?
>
>
> In fact, I am.
Cool!
> Give me a 3 lines description of where to start looking and I'll get going.
A good starting point is the BlocksManager and sitemap component
configurations in the test cases:
src/test/org/apache/cocoon/test/components/blocks/BlocksManagerTestCase.xconf.
/Daniel
Re: [Ann/RFC] "Sitemap Blocks"
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
>
>> Yey!!
>>
>> Daniel,
>>
>> you rock! Thanks so much for your continuous work on this!
>>
>>
> Thanks :)
>
>> See my comments inlined.
>>
>> Daniel Fagerstrom wrote:
>>
>>
> <snip/>
>
>>> The super block of a block is identified by
>>> /wiring/block/connections/connection/@name='super', see
>>> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/wiring.xml?view=markup
>>>
>>> for an example.
>>>
>>
>> hmmm, I don't get this. why do you need to explicitly identify a super
>> block? don't you get it directly thru extension?
>>
>>
> In block.xml you identify the super block with extension. But for the
> wiring.xml you just list the connections (name and block) to the other
> deployed blocks without any indication on what role they have (requires
> or extends). For the required blocks you get a name from block.xml for
> the extended block it doesn't have (or need to have) a name in block.xml
> but it need a name in wiring.xml so I just introduced the special name
> "super".
>
> Maybe it is not necessary to have the extended block at all in
> wiring.xml, but I prefer to have all deployment info available in
> wiring.xml. IMO it seem reasonable that if Í have a block that according
> to its block.xml extends
> http://cocoon.apache.org/blocks/another-block/1.0 it should be possible
> to deploy it so that it extends
> http://cocoon.apache.org/blocks/another-block/1.0.23.
gotcha. I don't have a problem with this.
>>> The wiring file is used by the BlocksManager to set up all the blocks.
>>> The BlocksManager is configured to point to the wiring.xml:
>>>
>>> <component role="org.apache.cocoon.components.blocks.BlocksManager"
>>> class="org.apache.cocoon.components.blocks.BlocksManager"
>>> file="wiring.xml"/>
>>>
>>> All access to blocks goes through the BlocksManager.
>>>
>>
>>
>> Works for me.
>>
>>
>>
>>> blocks: protocol
>>> ----------------
>>>
>>> The blocks mount paths from deployment should in principle be used
>>> before the main sitemap in the (main) webapp is called. But at this
>>> point I didin't want to touch the core classes e.g. o.a.c.Cocoon or let
>>> any core components depend on the block infrastrucuture. Therefore I
>>> instead created a blocks: protocol that can be used in the main sitemap
>>> to connect to the blocks system:
>>>
>>> <map:match pattern="**">
>>> <map:read src="blocks:/{1}"/>
>>> </map:match>
>>>
>>
>> Great idea! I'd like to keep going with this, because sometimes, due to
>> legacy, you might want to keep the need to position the 'block subspace'
>> as you please.
>>
>>
> I'm not certain that I actually supported "relocation" in the current
> implementation, but it shouldn't be that hard to fix.
ok
>>> block-path: module
>>> ------------------
>>>
>>> A block URI block:foo:/bar where the foo block is mounted at /test can
>>> be "absoultized" to /test/bar by using the block-path input module,
>>>
>>> {block-path:foo:/bar}
>>>
>>> see example in
>>> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test1/sub/.
>>>
>>> This module can be used together with the LinkRewriterTransformer
>>> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html
>>>
>>> from Forrest fame to creta the block link rewriting behaviour described
>>> in the end of http://wiki.apache.org/cocoon/BlocksDefinition.
>>>
>>
>>
>> this works, but I don't think it's the prettiest thing we could do.
>>
>>
> It wasn't designed to be pretty, it was designed to get the job done
> with a minimal amount of work ;)
>
>> A better way of achiving link translation would be to allow the
>> LinkRewritingTransformer to be aware of href="" and src="" attributes
>> (or configurable other attributes) and make them react on the same
>> block: protocol used above.
>>
> AFAIU, the LinkRewritingTransformer doesn't have any internal knowledge
> about anything, all actual link transformation is done in imput modules
> and connected to attributes and scemes in the configuration:
> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html.
> Highly flexible but not that easy to understand, but if we provide good
> default configuration files it shouldn't be a problem for the users.
>
>> so the link transformer must be able to
>> access the block manager and obtain the relative URL of the given stuff.
>>
>>
> Any component can find the current block and require it to "absolutize"
> a block: URL
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/components/modules/input/BlockPathModule.java?view=markup,
> so it wouldn't be a problemt to write a more a specialized block aware
> link transformer.
>
>> I would also go a little further and say that this behavior could be
>> *transparent* and part of the pipeline implementation itself, but I have
>> no strong opinion about this and I'm generally against behind-your-back
>> black magic.
>>
>>
> I prefer to avoid black magic in this case, link rewriting is hard
> enough to understand without any "helpfull" automagics. I might change
> my mind when we have got more experience about using block link
> rewriting, maybe it is so natural so that we can make it automatic
> without confusing ourselfes, but I'd rather wait and see.
Fair enough.
>> Another thing that might be helpful here, is to allow links to be
>> 'absolutized', when, for example, they need to be (say RSS feeds) and
>> the cocoon webapp is proxied.
>>
>> Link translation is hacky today and blocks will force us to think about
>> how to do it in a better way, let's keep also proxying, absolutization
>> and session IDs in mind as well.
>>
>>
> Agree.
>
>> thoughts?
>>
>>
> No ;) I think that the link rewriting that we allready have (although
> somewhat hacky) in the current block implementation, will simplify link
> handling quite a lot compared to th previous situation without blocks.
> But there is definitively more to do. If wou could write a more detailed
> analysis of link rewritiong it would be really helpfull.
no, I don't really care that much about making a change. So, I'll happy
let do-ocracy continue :-)
> --- o0o ---
>
> Now, to continue the work on the sitemap aspect of blocks we really need
> to apply it in a non trivial application. By doing that we will get more
> experience of the involved concepts. It would also make it easier for
> the rest of the community to see what the sitemap aspect of blocks can
> be used for. There seem to be a large community interest in the
> component aspect of blocks, but not yet in the sitemap aspect. Actually
> using it in a real use case would also increase my and others motivation
> to polish the implementation.
>
> I think that the Linotype would make an excelent use case for
> introducing the current block mechanism in. Are you interested?
In fact, I am.
Give me a 3 lines description of where to start looking and I'll get going.
--
Stefano.
Re: [Ann/RFC] "Sitemap Blocks"
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
>Yey!!
>
>Daniel,
>
>you rock! Thanks so much for your continuous work on this!
>
>
Thanks :)
>See my comments inlined.
>
>Daniel Fagerstrom wrote:
>
>
<snip/>
>>The super block of a block is identified by
>>/wiring/block/connections/connection/@name='super', see
>>http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/wiring.xml?view=markup
>>for an example.
>>
>>
>hmmm, I don't get this. why do you need to explicitly identify a super
>block? don't you get it directly thru extension?
>
>
In block.xml you identify the super block with extension. But for the
wiring.xml you just list the connections (name and block) to the other
deployed blocks without any indication on what role they have (requires
or extends). For the required blocks you get a name from block.xml for
the extended block it doesn't have (or need to have) a name in block.xml
but it need a name in wiring.xml so I just introduced the special name
"super".
Maybe it is not necessary to have the extended block at all in
wiring.xml, but I prefer to have all deployment info available in
wiring.xml. IMO it seem reasonable that if Í have a block that according
to its block.xml extends
http://cocoon.apache.org/blocks/another-block/1.0 it should be possible
to deploy it so that it extends
http://cocoon.apache.org/blocks/another-block/1.0.23.
>>The wiring file is used by the BlocksManager to set up all the blocks.
>>The BlocksManager is configured to point to the wiring.xml:
>>
>><component role="org.apache.cocoon.components.blocks.BlocksManager"
>> class="org.apache.cocoon.components.blocks.BlocksManager"
>> file="wiring.xml"/>
>>
>>All access to blocks goes through the BlocksManager.
>>
>>
>
>Works for me.
>
>
>
>>blocks: protocol
>>----------------
>>
>>The blocks mount paths from deployment should in principle be used
>>before the main sitemap in the (main) webapp is called. But at this
>>point I didin't want to touch the core classes e.g. o.a.c.Cocoon or let
>>any core components depend on the block infrastrucuture. Therefore I
>>instead created a blocks: protocol that can be used in the main sitemap
>>to connect to the blocks system:
>>
>> <map:match pattern="**">
>> <map:read src="blocks:/{1}"/>
>> </map:match>
>>
>>
>Great idea! I'd like to keep going with this, because sometimes, due to
>legacy, you might want to keep the need to position the 'block subspace'
>as you please.
>
>
I'm not certain that I actually supported "relocation" in the current
implementation, but it shouldn't be that hard to fix.
>>block-path: module
>>------------------
>>
>>A block URI block:foo:/bar where the foo block is mounted at /test can
>>be "absoultized" to /test/bar by using the block-path input module,
>>
>> {block-path:foo:/bar}
>>
>>see example in
>>http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test1/sub/.
>>This module can be used together with the LinkRewriterTransformer
>>http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html
>>from Forrest fame to creta the block link rewriting behaviour described
>>in the end of http://wiki.apache.org/cocoon/BlocksDefinition.
>>
>>
>
>this works, but I don't think it's the prettiest thing we could do.
>
>
It wasn't designed to be pretty, it was designed to get the job done
with a minimal amount of work ;)
>A better way of achiving link translation would be to allow the
>LinkRewritingTransformer to be aware of href="" and src="" attributes
>(or configurable other attributes) and make them react on the same
>block: protocol used above.
>
AFAIU, the LinkRewritingTransformer doesn't have any internal knowledge
about anything, all actual link transformation is done in imput modules
and connected to attributes and scemes in the configuration:
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html.
Highly flexible but not that easy to understand, but if we provide good
default configuration files it shouldn't be a problem for the users.
> so the link transformer must be able to
>access the block manager and obtain the relative URL of the given stuff.
>
>
Any component can find the current block and require it to "absolutize"
a block: URL
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/components/modules/input/BlockPathModule.java?view=markup,
so it wouldn't be a problemt to write a more a specialized block aware
link transformer.
>I would also go a little further and say that this behavior could be
>*transparent* and part of the pipeline implementation itself, but I have
>no strong opinion about this and I'm generally against behind-your-back
>black magic.
>
>
I prefer to avoid black magic in this case, link rewriting is hard
enough to understand without any "helpfull" automagics. I might change
my mind when we have got more experience about using block link
rewriting, maybe it is so natural so that we can make it automatic
without confusing ourselfes, but I'd rather wait and see.
>Another thing that might be helpful here, is to allow links to be
>'absolutized', when, for example, they need to be (say RSS feeds) and
>the cocoon webapp is proxied.
>
>Link translation is hacky today and blocks will force us to think about
>how to do it in a better way, let's keep also proxying, absolutization
>and session IDs in mind as well.
>
>
Agree.
>thoughts?
>
>
No ;) I think that the link rewriting that we allready have (although
somewhat hacky) in the current block implementation, will simplify link
handling quite a lot compared to th previous situation without blocks.
But there is definitively more to do. If wou could write a more detailed
analysis of link rewritiong it would be really helpfull.
--- o0o ---
Now, to continue the work on the sitemap aspect of blocks we really need
to apply it in a non trivial application. By doing that we will get more
experience of the involved concepts. It would also make it easier for
the rest of the community to see what the sitemap aspect of blocks can
be used for. There seem to be a large community interest in the
component aspect of blocks, but not yet in the sitemap aspect. Actually
using it in a real use case would also increase my and others motivation
to polish the implementation.
I think that the Linotype would make an excelent use case for
introducing the current block mechanism in. Are you interested?
/Daniel
Re: [Ann/RFC] "Sitemap Blocks"
Posted by Stefano Mazzocchi <st...@apache.org>.
Yey!!
Daniel,
you rock! Thanks so much for your continuous work on this!
See my comments inlined.
Daniel Fagerstrom wrote:
> I have added a first, hopefully working, version of the sitemap aspect
> of real blocks to the trunk. No functionality to get components (not
> even VPCs) yet from the blocks.
>
> Examples can be found in:
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/
> the implementation is supposed to follow
> http://wiki.apache.org/cocoon/Blocks and the result of various mail list
> discussions (although I can have missed things).
>
> Use
> ===
>
> FS layout
> ---------
>
> A block has the file system layout
>
> [cocoon block] [DIR]
> |
> +-- COB-INF [DIR]
> +-- block.xml
> +-- classes [DIR]
> +-- lib [DIR]
>
> according to http://wiki.apache.org/cocoon/BlocksFSLayout. Where
> block.xml is described in http://wiki.apache.org/cocoon/BlocksCob.
> [cocoon block] is like an ordinary Cocoon top level directory and
> typically contains a main sitemap, files and sub directories.
+1
> Configuration
> -------------
>
> block.xml describe where the main sitemap is and all component
> configurations are done from the main sitemap. Either directly in
> map:components or indirectly through an include
> http://svn.apache.org/repos/asf/cocoon/trunk/src/webapp/WEB-INF/cocoon.xconf.
> The code in COB-INF/[classes|lib] can be found throgh the local
> classloader
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111032234204889&w=2.
good
> The deployment configuration including URLs to the blocks is done in
> wiring.xml, http://wiki.apache.org/cocoon/BlocksWiring. Schemas for
> wiring.xml and block.xml can be found in
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/schema/. Currently no
> deployment tool is integrated so one have to write wiring.xml by hand.
that's fine.
> The super block of a block is identified by
> /wiring/block/connections/connection/@name='super', see
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/wiring.xml?view=markup
> for an example.
hmmm, I don't get this. why do you need to explicitly identify a super
block? don't you get it directly thru extension?
> The wiring file is used by the BlocksManager to set up all the blocks.
> The BlocksManager is configured to point to the wiring.xml:
>
> <component role="org.apache.cocoon.components.blocks.BlocksManager"
> class="org.apache.cocoon.components.blocks.BlocksManager"
> file="wiring.xml"/>
>
> All access to blocks goes through the BlocksManager.
Works for me.
> blocks: protocol
> ----------------
>
> The blocks mount paths from deployment should in principle be used
> before the main sitemap in the (main) webapp is called. But at this
> point I didin't want to touch the core classes e.g. o.a.c.Cocoon or let
> any core components depend on the block infrastrucuture. Therefore I
> instead created a blocks: protocol that can be used in the main sitemap
> to connect to the blocks system:
>
> <map:match pattern="**">
> <map:read src="blocks:/{1}"/>
> </map:match>
Great idea! I'd like to keep going with this, because sometimes, due to
legacy, you might want to keep the need to position the 'block subspace'
as you please.
> block: protocol
> ---------------
>
> The block: protocol, (http://wiki.apache.org/cocoon/BlocksDefinition and
> http://wiki.apache.org/cocoon/BlocksDefinition) the blocks version of
> the cocoon: protocol,
>
> block:/test
>
> will call the pipeline with URI test in the root sitemap of the current
> block.
>
> block:./test
>
> will call the pipeline with URI test in the current sitemap of the
> current block. In both cases block inheritance and polymorphism are
> respected (take a look at
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test3/
> for examples). The reason for not using "://" and ":/" for absolute and
> relative addressing as for the cocoon: protocol is that it doesn't
> follow the http://www.ietf.org/rfc/rfc3986.txt, see
> http://www.betaversion.org/~pier/wiki/display/pier/Cocoon+and+URIs for
> Pier's rant about it.
>
> block:foo:/test
>
> will call the pipeline with URI /test in the block. The extended block
> can be explicitly called by,
>
> block:super:/test
+1
> block-property: module
> ----------------------
>
> A block can have a number of properties that can be given default values
> in block.xml and deployment values in wiring.xml (see examples in
> test3/). The value of a property in the current block can be accessed
> with an input-module,
>
> {block-property:foo}
>
> There is no access to properties in other blocks. The blocks properties
> can be used for things like db URLs and should IMO be block private.
+1
> block-path: module
> ------------------
>
> A block URI block:foo:/bar where the foo block is mounted at /test can
> be "absoultized" to /test/bar by using the block-path input module,
>
> {block-path:foo:/bar}
>
> see example in
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test1/sub/.
> This module can be used together with the LinkRewriterTransformer
> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html
> from Forrest fame to creta the block link rewriting behaviour described
> in the end of http://wiki.apache.org/cocoon/BlocksDefinition.
this works, but I don't think it's the prettiest thing we could do.
A better way of achiving link translation would be to allow the
LinkRewritingTransformer to be aware of href="" and src="" attributes
(or configurable other attributes) and make them react on the same
block: protocol used above. so the link transformer must be able to
access the block manager and obtain the relative URL of the given stuff.
I would also go a little further and say that this behavior could be
*transparent* and part of the pipeline implementation itself, but I have
no strong opinion about this and I'm generally against behind-your-back
black magic.
Another thing that might be helpful here, is to allow links to be
'absolutized', when, for example, they need to be (say RSS feeds) and
the cocoon webapp is proxied.
Link translation is hacky today and blocks will force us to think about
how to do it in a better way, let's keep also proxying, absolutization
and session IDs in mind as well.
thoughts?
--
Stefano.
Re: [Ann/RFC] "Sitemap Blocks"
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> I have added a first, hopefully working, version of the sitemap aspect
>> of real blocks to the trunk. No functionality to get components (not
>> even VPCs) yet from the blocks.
>
> Many thanks mate!!! I will give you feedback on the issues that I can
> comment on as soon as possible over the next days.
Looking forward to get feedback :)
> Just being curious: What do you think how difficult will it be to
> integrate the OSGi layer beneath your infrastructure? (Yes, I read your
> RT but I'm intersted in your thoughts after reaching the first milestone
> of blcoks implementation.)
I have not thought that much more on OSGi integration, so the RT still
reflects my current ideas. I plan to start experimenting with OSGi in
the whiteboard ASAP if no one protests. Then we should get a better idea
about the issues.
Things that still are unclear to me is how the "Cocoon service" should
find the wiring info or the main sitemap in a convenient way in OSGi.
Although it is not needed for getting a first version of real blocks I
think we will need to spend much work on spliting the core into smaller
pieces and to be much more clear about what is api and what is
implementation.
/Daniel
Re: [Ann/RFC] "Sitemap Blocks"
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> I have added a first, hopefully working, version of the sitemap aspect
> of real blocks to the trunk. No functionality to get components (not
> even VPCs) yet from the blocks.
Many thanks mate!!! I will give you feedback on the issues that I can comment on
as soon as possible over the next days.
Just being curious: What do you think how difficult will it be to integrate the
OSGi layer beneath your infrastructure? (Yes, I read your RT but I'm intersted
in your thoughts after reaching the first milestone of blcoks implementation.)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de