You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2005/06/20 10:53:05 UTC
Locationmap and sitemap.selector.exists
Hello devs,
I have a question about the locationmap.
I wonder whether if it is possible to use a sitemap.selector.exists
within my locationmap.xml?
I reckon it is possible and I will just try it out, but I would like
your opinion about the resulting code.
I want to re-factor the output.xmap from the viewHelper.xhtml that I
will add all the <map:select type="exists"> into the locationmap. e.g.
<map:match pattern="resolve.contract.xhtml.*">
<map:select type="exists">
<map:when test="{project:resources}/templates/{1}.ft">
<map:generate src="{project:resources}/templates/{1}.ft"/>
</map:when>
<map:when test="resources/templates/{1}.ft">
<map:generate src="resources/templates/{1}.ft"/>
</map:when>
<map:otherwise>
<map:generate src="resources/templates/noFt.ft"/>
</map:otherwise>
</map:select>
<map:serialize type="xml"/>
</map:match>
should go in the locationmap.xml and then I can get rid of this match in
the output.xmap and later on match directly:
<map:match pattern="get.contract.*.xhtml">
<map:generate src="{lm:templates/{1}.ft}"/>
<map:transform src="resources/stylesheets/contract.xsl">
<!--Which output format?-->
<map:parameter name="format" value="xhtml"/>
</map:transform>
<map:transform type="i18n">
<map:parameter name="locale" value="{request:locale}"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>
Trying to ask, whether it should/is best practice to resolve in the
locationmap the resources with the help of sitemap.selector.exists?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Locationmap and sitemap.selector.exists
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2005-06-21 at 08:20 +0200, Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> ...
> > Another use case for what you suggest is the resources.xmap file.
> > Imagine how much easier to follow it would be if we didn't have so may
> > alternative locations for the image files. Nicola Ken hinted that this
> > would be the case when I recently said I don't want to think that far
> > forward yet. I wonder if this is what he meant?
>
> Yes. As Thorsten has seen, Having the information early can make the
> sitemaps much cleaner.
>
> But instead of "exists", we should use another selector. Let me explain.
>
> Cocoon has the notion of "Source", and there is also a
> "TraversableSource". This means that I can go further than asking a
> source if a file exists, I can ask to give me all the files that have a
> given name except the extension. This would make it all much faster and
> cleaner.
>
> For example, if the TraversableSource is the file system, my action
> would ask all the filenames in a certain directory, and with a for loop
> get all the ones with the same name in the requested URI, sorting the
> extensions as I tell him to. In this way, the result of the processing
> is *one* *source* *file*!
>
That is why you always have been talking about:
about.xml
about.meta.xml
...
right?
The question that raises is whether that is working as well for
subdirectories. Let me explain:
I have a contract not only in {project:resources}/templates/ but in e.g.
{project:resources}/templates/xhtml/{1}.ft
{project:resources}/templates/fo/{1}.ft
Now would the TraversableSource respond me when looking for {1} the fo/
and the xhtml/ dir location or only in one dir (without subdir)?
What do you exactly mean with *one* *source* *file*?
Do you mean eg. index.xml and index.fv can be treated as *one* file
because their have only the extension different?
> Imagine, from the very beginning we know what the source is without
> lengthy and tedious requests, and we can start processing by knowing
> what the source is from the beginning.
> Separation of Concerns: location resolving and processing fully
> separate, also inside Cocoon.
>
Requesting index.html would give me index.xml and index.fv through the
TraversableSource (in locationmap). This resolving would then be used
later on in the processing which will not care about resolving but
concentrate on processing. That makes the sitemap really clean and
readable. :)
¡¡¡wow!!!
Now I am starting to understand better what you wrote in old mails. ;-)
Good on ya, mate.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Locationmap and sitemap.selector.exists
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
...
> Another use case for what you suggest is the resources.xmap file.
> Imagine how much easier to follow it would be if we didn't have so may
> alternative locations for the image files. Nicola Ken hinted that this
> would be the case when I recently said I don't want to think that far
> forward yet. I wonder if this is what he meant?
Yes. As Thorsten has seen, Having the information early can make the
sitemaps much cleaner.
But instead of "exists", we should use another selector. Let me explain.
Cocoon has the notion of "Source", and there is also a
"TraversableSource". This means that I can go further than asking a
source if a file exists, I can ask to give me all the files that have a
given name except the extension. This would make it all much faster and
cleaner.
For example, if the TraversableSource is the file system, my action
would ask all the filenames in a certain directory, and with a for loop
get all the ones with the same name in the requested URI, sorting the
extensions as I tell him to. In this way, the result of the processing
is *one* *source* *file*!
Imagine, from the very beginning we know what the source is without
lengthy and tedious requests, and we can start processing by knowing
what the source is from the beginning.
Separation of Concerns: location resolving and processing fully
separate, also inside Cocoon.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Locationmap and sitemap.selector.exists
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> Hello devs,
>
> I have a question about the locationmap.
>
> I wonder whether if it is possible to use a sitemap.selector.exists
> within my locationmap.xml?
>
> I reckon it is possible and I will just try it out, but I would like
> your opinion about the resulting code.
I also believe it is possible, but have yet to try it. The
implementation reuses Cocoon sitemap components to build the
locationmap, therefore it should be possible to us any existing sitemap
components.
> I want to re-factor the output.xmap from the viewHelper.xhtml that I
> will add all the <map:select type="exists"> into the locationmap. e.g.
>
> <map:match pattern="resolve.contract.xhtml.*">
> <map:select type="exists">
> <map:when test="{project:resources}/templates/{1}.ft">
> <map:generate src="{project:resources}/templates/{1}.ft"/>
> </map:when>
> <map:when test="resources/templates/{1}.ft">
> <map:generate src="resources/templates/{1}.ft"/>
> </map:when>
> <map:otherwise>
> <map:generate src="resources/templates/noFt.ft"/>
> </map:otherwise>
> </map:select>
> <map:serialize type="xml"/>
> </map:match>
>
> should go in the locationmap.xml and then I can get rid of this match in
> the output.xmap and later on match directly:
> <map:match pattern="get.contract.*.xhtml">
> <map:generate src="{lm:templates/{1}.ft}"/>
> <map:transform src="resources/stylesheets/contract.xsl">
> <!--Which output format?-->
> <map:parameter name="format" value="xhtml"/>
> </map:transform>
> <map:transform type="i18n">
> <map:parameter name="locale" value="{request:locale}"/>
> </map:transform>
> <map:serialize type="xml"/>
> </map:match>
>
> Trying to ask, whether it should/is best practice to resolve in the
> locationmap the resources with the help of sitemap.selector.exists?
There is no best practice yet (at least I'm not aware of one). What you
suggest certainly "feels" right because the logic of the processing
remains in the sitemap, but the resolving of files goes in the locationmap.
Another use case for what you suggest is the resources.xmap file.
Imagine how much easier to follow it would be if we didn't have so may
alternative locations for the image files. Nicola Ken hinted that this
would be the case when I recently said I don't want to think that far
forward yet. I wonder if this is what he meant?
I'd say go for it and lets see what the implications are as we experiment.
Ross