You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Reinhard Poetz <re...@apache.org> on 2005/01/24 10:11:50 UTC
Forrest 0.6 - stable?
Do you consider the structure of Forrest 0.6 repositories as stable? I've seen
that forrestbot on brutus, that uses Forrest 0.7, builds my Forrest 0.6 project
perfectly.
Can I trust that Forrest 1.0 will build my 0.6 projects *without* having to
modify configuration files too or do already know of incompatible future changes
that have to happen?
--
Reinhard
Re: LocationMap (was Re: Forrest 0.6 - stable?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Johannes Schaefer wrote:
> Has this something to do with the linkmap?
> See
> http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=user@forrest.apache.org&msgNo=1617
Yes and no :-)
They are two different things that together with skinconf.xml and
forrest.properties form the basic config documents that Forrest uses.
A linkmap, AKA site.xml, is for associating links with a name and making
a navigation of the site.
A locationmap is instead a file that describes where Forrest should look
for source files.
For example, let's say that you want all ./build/myreport/* files be
used by Forrest to generate the projectdocs/reports/rep/* files: with
the locationmap you can... once it's included in the mechanism :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: LocationMap (was Re: Forrest 0.6 - stable?)
Posted by Johannes Schaefer <jo...@uidesign.de>.
Has this something to do with the linkmap?
See
http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=user@forrest.apache.org&msgNo=1617
Johannes
Nicola Ken Barozzi wrote:
> Reinhard Poetz wrote:
>
>> Nicola Ken Barozzi wrote:
>
> ...
>
>>> IMHO they will change in 0.8, with the introduction of the locationmap.
>>
>>
>> Can you give me a pointer to "locationmap"?
>
>
> Hmmm... it's in the mail archives ;-)
>
> Ok, well it's about describing where the sources for Forrest are with a
> special "sitemap" called "locationmap". The code is in SVN since ages,
> but we have not yet put it to good use.
>
> I'm adding the first mail from Unico about it below.
> It's in the thread named "LocationMapModule".
>
> - 0 -
>
> A locationmap defines a mapping from requests to location strings.
>
> It was conceived to:
>
> a) Provide a more powerful means for semantic linking.
> b) Enable Forrest with a standard configuration override mechanism.
>
> The syntax of a locationmap resembles that of the sitemap in that it
> also makes use of Matchers and Selectors to traverse a tree of nodes
> towards a leaf. In the case of the locationmap however the leaf does not
> identify a pipeline but instead identifies a location string.
>
> -- o --
>
> An example:
> -----------
>
> <locationmap xmlns="http://apache.org/cocoon/locationmap/1.0">
>
> <!--
> + Components section: define Matchers and Selectors here.
> + The current implementation only supports a subset of
> + the Avalon lifecycles. Only those that are actually
> + implemented by the currently available Selectors and Matchers.
> + Moreover, it expects them to be ThreadSafe (which all of them are IIRC)
> + -->
> <components>
> <matchers default="parameter">
> <matcher
> name="parameter"
> src="org.apache.cocoon.matching.WildcardParameterMatcher">
> <!--
> + #lm:name is a special parameter that is passed into
> + the Matcher by the LocationMap implementation.
> + It identifies the name string the module was called
> + with. For example when calling the module as follows:
> + {lm:/my/virtual/path} the parameters value will
> + be /my/virtual/path .
> + -->
> <parameter>#lm:name</parameter>
> </matcher>
> <matcher
> name="request"
> src="org.apache.cocoon.matching.WildcardURIMatcher"
> />
> </matchers>
> <selectors default="exists">
> <selector
> name="exists"
> src="org.apache.cocoon.selecting.ResourceExistsSelector"
> />
> </selectors>
> </components>
>
> <!--
> + Locator section.
> + A locator groups matchers and selectors and provides a base location
> + locations are resolved against.
> + The locator below exemplifies how a locator could be used
> + to enable clients to override resource locations.
> + -->
> <locator base="."> <!-- resolves to the current sitemap context -->
> <!--
> + locate skin stylesheets by searching fs locations
> /forrest/styles/{1}
> + and /hippo/styles/{1} respectively.
> + if none exist default to ./styles/
> + -->
> <match pattern="**.html" type="request">
> <select type="exists">
> <location src="file://unico/styles/{1}.xsl" />
> <location src="file://hippo/styles/{1}.xsl" />
> </select>
> <location src="styles/{1}.xsl" />
> </match>
> </locator>
>
> <!--
> + This locator exemplifies how to use a locationmap for
> + link resolving. Note the use of the parameter
> + type matcher. This one has been defined above to match
> + the special '#lm:name' parameter that holds a reference
> + to the argument the input module was called with.
> + -->
> <locator base=".">
> <match pattern="xdocs/**.xml" type="parameter">
> <match pattern="xdocs/news/*/*/*/today.xml">
> <location src="news/archive/{3}{2}{1}.html" />
> </match>
> <location src="{1}.html" />
> </match>
> </locator>
> </locationmap>
>
>
> -- o --
>
>
> In the first example a sitemap would be able to do something like:
>
> sitemap.xmap:
> <map:match pattern="**.html">
> <map:generate src="xdocs/{1}.xml" />
> <map:transform src="{lm:}" type="xslt" />
> <map:serialize type="html" />
> </map:match>
>
> Note the usage of the locationmap module: {lm:}. The input module
> argument is empty because it is not used in the locationmap anyway (the
> matcher used is of type request).
>
> In the second usage scenario the idea is that xdocs in a repository are
> only aware of their relative locations. What URL they are mapped to in a
> website is not their concern. Therefore there needs to be a translation
> between links between documents within an xml repository and their
> locations on a website. This is very similar to semantic linking where
> editors define a virtual link and that link gets mapped to an actual
> location by a module that knows where the page is currently located
> (such as one reading a forrest site.xml file). The difference is that
> the source links are actually not virtual semantic identifiers at all
> but physical system identifiers, only relative to a seperate system than
> the target one. The LocationMap accommodates a complete mapping from any
> source location to any target location.
>
> In scenario the module is used by a LinkRewriterTransformer:
>
> sitemap.xmap:
> <map:match pattern="**.html">
> <map:generate src="repo/**.xml" />
> <map:transform src="content2page.xsl" type="xslt" />
> <map:transform type="linkrewriter" />
> <map:serialize type="html" />
> </map:match>
>
> repo/{1}.xml:
> <document>
> <title>How to use locationmaps</title>
> <related href="repo:xdocs/news/10/10/2002/today.xml" />
> <related href="repo:xdocs/news/02/02/2001/today.xml" />
> <body>blah</body>
> </document>
>
> {1}.html:
> <html>
> <title>How to use locationmaps</title>
> <body>
> <p>blah</p>
> See also:
> <p><a href="news/archive/20021010.html">related news<a></p>
> <p><a href="news/archive/20010202.html">related news<a></p>
> </body>
> </html>
>
> -- o --
>
> Issues and Notes.
> -----------------
>
> The reason for the 'archored' syntax of special variables #lm:name and
> #lm:base is due to the fact that the treeprocessor code for variable
> resolution which I reused provides a way to declare global variables
> that way.
>
> The reuse of Matcher and Selectors makes the locationmap very powerful.
> However, especially the Selector concept is not an exact fit when used
> in the context of a locationmap. This is because the test string that is
> passed to the selector in a locationmap has a more specific meaning than
> the test strings that are passed to it in the sitemap. In the
> locationmap's case it is the resolved location src attribute, whereas in
> a sitemap it can be anything because it is explicitly passed in as
> <map:when test="{something}"/>. Therefore some selectors do not make
> sense in the context of a locationmap (f.e. a HostSelector).
>
> Nothing in the code indicates that <location src="something" /> is
> interpreted as a location string per se. It can in fact be anything. Its
> only semantic constraint is that it is a string literal.
>
>
>
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634
Ludwigsburg
Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH *
Lehrer-Götz-Weg 11 * D-81825 München
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael
Burmester
www.user-interface-tuning.de
Attraktivität von interaktiven Produkten messen mit
www.attrakdiff.de
LocationMap (was Re: Forrest 0.6 - stable?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Reinhard Poetz wrote:
> Nicola Ken Barozzi wrote:
...
>> IMHO they will change in 0.8, with the introduction of the locationmap.
>
> Can you give me a pointer to "locationmap"?
Hmmm... it's in the mail archives ;-)
Ok, well it's about describing where the sources for Forrest are with a
special "sitemap" called "locationmap". The code is in SVN since ages,
but we have not yet put it to good use.
I'm adding the first mail from Unico about it below.
It's in the thread named "LocationMapModule".
- 0 -
A locationmap defines a mapping from requests to location strings.
It was conceived to:
a) Provide a more powerful means for semantic linking.
b) Enable Forrest with a standard configuration override mechanism.
The syntax of a locationmap resembles that of the sitemap in that it
also makes use of Matchers and Selectors to traverse a tree of nodes
towards a leaf. In the case of the locationmap however the leaf does not
identify a pipeline but instead identifies a location string.
-- o --
An example:
-----------
<locationmap xmlns="http://apache.org/cocoon/locationmap/1.0">
<!--
+ Components section: define Matchers and Selectors here.
+ The current implementation only supports a subset of
+ the Avalon lifecycles. Only those that are actually
+ implemented by the currently available Selectors and Matchers.
+ Moreover, it expects them to be ThreadSafe (which all of them are IIRC)
+ -->
<components>
<matchers default="parameter">
<matcher
name="parameter"
src="org.apache.cocoon.matching.WildcardParameterMatcher">
<!--
+ #lm:name is a special parameter that is passed into
+ the Matcher by the LocationMap implementation.
+ It identifies the name string the module was called
+ with. For example when calling the module as follows:
+ {lm:/my/virtual/path} the parameters value will
+ be /my/virtual/path .
+ -->
<parameter>#lm:name</parameter>
</matcher>
<matcher
name="request"
src="org.apache.cocoon.matching.WildcardURIMatcher"
/>
</matchers>
<selectors default="exists">
<selector
name="exists"
src="org.apache.cocoon.selecting.ResourceExistsSelector"
/>
</selectors>
</components>
<!--
+ Locator section.
+ A locator groups matchers and selectors and provides a base location
+ locations are resolved against.
+ The locator below exemplifies how a locator could be used
+ to enable clients to override resource locations.
+ -->
<locator base="."> <!-- resolves to the current sitemap context -->
<!--
+ locate skin stylesheets by searching fs locations
/forrest/styles/{1}
+ and /hippo/styles/{1} respectively.
+ if none exist default to ./styles/
+ -->
<match pattern="**.html" type="request">
<select type="exists">
<location src="file://unico/styles/{1}.xsl" />
<location src="file://hippo/styles/{1}.xsl" />
</select>
<location src="styles/{1}.xsl" />
</match>
</locator>
<!--
+ This locator exemplifies how to use a locationmap for
+ link resolving. Note the use of the parameter
+ type matcher. This one has been defined above to match
+ the special '#lm:name' parameter that holds a reference
+ to the argument the input module was called with.
+ -->
<locator base=".">
<match pattern="xdocs/**.xml" type="parameter">
<match pattern="xdocs/news/*/*/*/today.xml">
<location src="news/archive/{3}{2}{1}.html" />
</match>
<location src="{1}.html" />
</match>
</locator>
</locationmap>
-- o --
In the first example a sitemap would be able to do something like:
sitemap.xmap:
<map:match pattern="**.html">
<map:generate src="xdocs/{1}.xml" />
<map:transform src="{lm:}" type="xslt" />
<map:serialize type="html" />
</map:match>
Note the usage of the locationmap module: {lm:}. The input module
argument is empty because it is not used in the locationmap anyway (the
matcher used is of type request).
In the second usage scenario the idea is that xdocs in a repository are
only aware of their relative locations. What URL they are mapped to in a
website is not their concern. Therefore there needs to be a translation
between links between documents within an xml repository and their
locations on a website. This is very similar to semantic linking where
editors define a virtual link and that link gets mapped to an actual
location by a module that knows where the page is currently located
(such as one reading a forrest site.xml file). The difference is that
the source links are actually not virtual semantic identifiers at all
but physical system identifiers, only relative to a seperate system than
the target one. The LocationMap accommodates a complete mapping from any
source location to any target location.
In scenario the module is used by a LinkRewriterTransformer:
sitemap.xmap:
<map:match pattern="**.html">
<map:generate src="repo/**.xml" />
<map:transform src="content2page.xsl" type="xslt" />
<map:transform type="linkrewriter" />
<map:serialize type="html" />
</map:match>
repo/{1}.xml:
<document>
<title>How to use locationmaps</title>
<related href="repo:xdocs/news/10/10/2002/today.xml" />
<related href="repo:xdocs/news/02/02/2001/today.xml" />
<body>blah</body>
</document>
{1}.html:
<html>
<title>How to use locationmaps</title>
<body>
<p>blah</p>
See also:
<p><a href="news/archive/20021010.html">related news<a></p>
<p><a href="news/archive/20010202.html">related news<a></p>
</body>
</html>
-- o --
Issues and Notes.
-----------------
The reason for the 'archored' syntax of special variables #lm:name and
#lm:base is due to the fact that the treeprocessor code for variable
resolution which I reused provides a way to declare global variables
that way.
The reuse of Matcher and Selectors makes the locationmap very powerful.
However, especially the Selector concept is not an exact fit when used
in the context of a locationmap. This is because the test string that is
passed to the selector in a locationmap has a more specific meaning than
the test strings that are passed to it in the sitemap. In the
locationmap's case it is the resolved location src attribute, whereas in
a sitemap it can be anything because it is explicitly passed in as
<map:when test="{something}"/>. Therefore some selectors do not make
sense in the context of a locationmap (f.e. a HostSelector).
Nothing in the code indicates that <location src="something" /> is
interpreted as a location string per se. It can in fact be anything. Its
only semantic constraint is that it is a string literal.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest 0.6 - stable?
Posted by Reinhard Poetz <re...@apache.org>.
Nicola Ken Barozzi wrote:
> Reinhard Poetz wrote:
>
>>
>> Do you consider the structure of Forrest 0.6 repositories as stable?
>
>
> No.
>
>> I've seen that forrestbot on brutus, that uses Forrest 0.7, builds my
>> Forrest 0.6 project perfectly.
>
>
> That's nice to hear :-)
>
>> Can I trust that Forrest 1.0 will build my 0.6 projects *without*
>> having to modify configuration files too or do already know of
>> incompatible future changes that have to happen?
>
>
> The configuration files will change, but there should/will be a
> conversion system, so it should not be a problem.
thank you
>
> IMHO they will change in 0.8, with the introduction of the locationmap.
Can you give me a pointer to "locationmap"?
--
Reinhard
Re: Forrest 0.6 - stable?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Reinhard Poetz wrote:
>
> Do you consider the structure of Forrest 0.6 repositories as stable?
No.
> I've seen that forrestbot on brutus, that uses Forrest 0.7, builds my
> Forrest 0.6 project perfectly.
That's nice to hear :-)
> Can I trust that Forrest 1.0 will build my 0.6 projects *without* having
> to modify configuration files too or do already know of incompatible
> future changes that have to happen?
The configuration files will change, but there should/will be a
conversion system, so it should not be a problem.
IMHO they will change in 0.8, with the introduction of the locationmap.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------