Re: [Ann/RFC] Sitemap Blocks
To make it easier to test the sitemap blocks I just added a simple sample to trunk. It is rather primitive and doesn't illustrate all features. There is one block sample, that contains sitemap, stylesheet etc for rendering the Cocoon samples. It also contains an example sample.xml that is prepared to be polymorphically overiden by extending blocks, by being used through the block: protocol in the sitemap. Linkrewriting is also illustrated which requires that the linkrewriter block is included. There is another block mysample that extend the sample block and overides sample.xml. The blocks are situated in webapp/WEB-INF/blocks and the wiring.xml that describes how the blocks are mounted is directly under webapp. The blocks are mounted through the blocks: protocol in the main sitemap. The normal use is that all the blocks: protocol always is used at the root level, but as that would have shadowed the other samples I had to mount the blocks one step down which made it a little bit hacky. The samples is tested by pointing the browser at: http://localhost:/blocks-test/sample/ and http://localhost:/blocks-test/mysample/ /Daniel
Re: [Ann/RFC] Sitemap Blocks
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
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.
Re: [Ann/RFC] Sitemap Blocks
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
Re: [Ann/RFC] Sitemap Blocks
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
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-devm=111032234204889w=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
Re: [Ann/RFC] Sitemap Blocks
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
Re: [Ann/RFC] Sitemap Blocks
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
[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-devm=111032234204889w=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
