forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject 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.internal.view/resources/stylesheets/ whiteboard/plugi...)
Date Wed, 24 Aug 2005 13:36:52 GMT
Thorsten Scherler wrote:
> On Mon, 2005-08-22 at 18:13 +0100, Ross Gardler wrote:
> 
>>Thorsten Scherler wrote:
>>
>>>On Fri, 2005-08-19 at 09:52 +0100, Ross Gardler wrote:
>>>
>>>
>>>>thorsten@apache.org wrote:
>>>>
>>>>
>>>>>Author: thorsten
>>>>>Date: Thu Aug 18 17:44:00 2005
>>>>>New Revision: 233401
>>>>>
>>>>
>>>>...
>>>>
>>>>
>>>>
>>>>>Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/src/java/org/apache/forrest/plugin/internal/view/acting/FallbackResolverAction.java
>>>>
>>>>Does this fallback resolver work with the locationmap?
>>>>
>>>
>>>
>>>What do you mean?
>>
>>Can I use, for example {lm:{1}} as a URI.
>>
>>
>>>>What does this do that the locationmap does not do?
>>>>
>>>
>>>
>>>It computes a dynamic path for fallback file.
>>
>>...
>>
>>
>>>The locationmap needs to be defined and edited. All fallbacks that you
>>>want to use, you have to define before, not very suitable for a high
>>>dynamic environment like views. 
>>
>>Well something must be telling the fallback where to look. If you change 
>>the defaults that file must be edited too. So there is no difference here.
>>
> 
> 
> I do not see how the locationmap can help me with that and I see one big
> differents:
> <match pattern="rewriteDemo/**">
> <select>
>  <location src="http://www.burrokeet.org/{1}.fv" />
> <!--How can you have dir fallbacks without defining the dir structure
> here?-->
>  <location src="http://www.burrokeet.org/{dir}{1}.fv" />
>  <location src="http://www.burrokeet.org/default.fv" />
> </select>
> </match>
> 
> Due to the fact that it is a "simple" matcher/select/location mechanism
> I cannot compute something like the fallback dir view like the action is
> doing. If I can then please show me an example. Like I see it I need to
> define all possible locations in a lm.

I think Tims response provides an example, I'm replying in that part of 
the thread.

> That is not suitable for views because an user cannot define *all*
> possible locations. That would mean (s)he has to define all
> subdirectories of h(er)is site and their fallback in the lm. ...or do I
> miss something about the locationmap?

There is now the potential for a default forrest locatonmap which will 
import the user locationmap. Therefore Forrest defines the defaults and 
the user can define any extra. In other words it is the same as in your 
fallback resolver in which the defaults are defined in the resolver itself.

>>See http://issues.apache.org/jira/browse/FOR-576 and notice it is Tim 
>>who got this to work so it may be better to have is opinion.
>>
> 
> 
> see above, you end up defining all fallbacks there. 
> 
> 
>>If I understand you the functionality is the same, and appears to be 
>>more flexible in the locationmap (although I'm in a noisy net cafe and 
>>cannot concentrate fully). Can we stick to just one solution?
> 
> 
> Yes, why not, but the locationmap is not a solution to my problem right
> now, that is how I personally see it. If you can provide an example how
> the lm is solving the fallback mechanism for views without defining all
> the fallbacks in the lm then I will be more then happy to use it. 

Do you meand "the user defining all the fallbacks"? in the sense of 
Forrest defining some locations and the user (optionally) defining some. 
If so I address this above, otherwise I don't understand your point, 
please expand.

Ross

Mime
View raw message