Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401 - in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/ whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.inte

[Thorsten Scherler <th...@apache.org>]

On Mon, 2005-08-22 at 16:29 -0400, Tim Williams wrote:

> Assuming I understand what this is doing, I don't immediately see why
> this couldn't be done with either the locationmap or a
> ResourceExistsSelector in the sitemap itself.

We had the ResourceExistsSelector in the views sitemaps (and some parts
are still using this selector). The FallbackResolverAction is an attempt
to have a cleaner sitemap.

>   Below is a very rough
> idea of what the locationmap version of this would be I think.  Maybe
> there's something that the FallbackResolver is doing that I'm just not
> "seeing" though?
> 

Requesting 
http://localhost:8888/samples/sample.html

The FallbackResolverAction.java will try:
1) xdocs/samples/sample.{project:theme-ext}
2) xdocs/samples/{project:theme}.{project:theme-ext}
3) xdocs/{project:theme}.{project:theme-ext}
4) {defaults:view-themes}/{project:theme}.{project:theme-ext}
5) {defaults:view-themes}/{project:theme}.{defaults:theme-ext}

The FallbackResolver is "looping" through the directories downwards till
the last project specific fallback is reached.

How can I implement this recursive looping behavior (1,2) in the lm? The
important part is that the incoming request would be "samples/sample"
for {1}. 

>     <map:match pattern="prepare.view.**">
>       <map:generate src="{lm:prepare.view.{1}}"/>
>       <map:transform src="resources/stylesheets/prepare.include.templates.xsl"/>
>       <map:transform type="xinclude"/>
>       <map:serialize type="xml"/>
>     </map:match>
>     
>     <locator>
>       <match pattern="prepare.view.**.*">
>         <select>    
>           <location src="{1}.{2}"/>
>           <location src="{project:theme}{1}.{project:theme-ext}"/>
>           <location src="{project:content.xdocs}{1}.{project:theme-ext}"/>
>           <location src="{defaults:view-themes}...
>           <location src="{defaults:theme}...
>         </select>
>       </match>
>     </locator>

This example is missing the looping. Anyway, thanks for giving it. :)

> --tim
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401 - in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/ whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.inte

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> On Mon, 2005-08-22 at 16:29 -0400, Tim Williams wrote:
> 
> 
>>Assuming I understand what this is doing, I don't immediately see why
>>this couldn't be done with either the locationmap or a
>>ResourceExistsSelector in the sitemap itself.
> 
> 
> We had the ResourceExistsSelector in the views sitemaps (and some parts
> are still using this selector). The FallbackResolverAction is an attempt
> to have a cleaner sitemap.

Yes, same goal of the selector in the Locationmap.

>>  Below is a very rough
>>idea of what the locationmap version of this would be I think.  Maybe
>>there's something that the FallbackResolver is doing that I'm just not
>>"seeing" though?
>>
> 
> 
> Requesting 
> http://localhost:8888/samples/sample.html
> 
> The FallbackResolverAction.java will try:
> 1) xdocs/samples/sample.{project:theme-ext}
> 2) xdocs/samples/{project:theme}.{project:theme-ext}
> 3) xdocs/{project:theme}.{project:theme-ext}
> 4) {defaults:view-themes}/{project:theme}.{project:theme-ext}
> 5) {defaults:view-themes}/{project:theme}.{defaults:theme-ext}
> 
> The FallbackResolver is "looping" through the directories downwards till
> the last project specific fallback is reached.

> How can I implement this recursive looping behavior (1,2) in the lm? The
> important part is that the incoming request would be "samples/sample"
> for {1}. 

What do you mean recursive "looping"? I don't see a loop above. I see 5 
alternative locations, each of which will be tested for the location of 
the file, if it exists it will be loaded, if not the next will be tried.

What part of this is a recursive loop and why?

Lets find a way of getting the required functionlaity into the 
locationmap, but first we need to understand why this is not currently 
possible.

When I get back home (end of this week). I'll spend some time digesting 
your fallback resolver and its use.

Ross


Ross