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.inte
Date Fri, 26 Aug 2005 11:09:53 GMT
Thorsten Scherler wrote:

>On Wed, 2005-08-24 at 09:54 -0400, Tim Williams wrote:
>...
>  
>
>>>>>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.
>>>      
>>>
>>Here's what I think I understand of the problem.  His fallbacks work
>>like this in order:
>>
>>1. File-based 
>>2. Directory-based
>>3. Parent-directory based (recursively)
>>4. Theme based
>>5. Application Default
>>
>>    
>>
>
>Yes, that is right. I will add a doctype specific fallback as well the
>next days which I am right now developing. 
>
>  
>
>>Ok, maybe not exactly, but it gives the general idea.  Anyway,
>>locationmaps can solve all of those except, I think, #3.  We have no
>>ability to do a "..\" up the directory tree until we find it. We can't
>>dissect the "matcher" result enough to do it either if that makes any
>>sense.  I think either way we're probably going to need some java code
>>to do this stuff.  
>>    
>>
>
>exactly!!! Thanks for writing this down so spot on, Tim. :) 
>  
>
Yes, thanks Tim, I now understand.

>>One might argue that it should be a new selector I
>>suppose -- in which case, I'd say that it should only handle the
>>generic directory traversing part and not forrest-specific defaults. 
>>In other words, implement the recursive directory traversal with a new
>>selector and use the built-in capability of the lm to do the rest --
>>that'd give us a more generic directory traversing selector.
>>    
>>
>
>Agreed (partly). ;-) The design of the action is quite generic already
>and could be reused in any cocoon based app that needs fallbacks, anyway
>the combination like you suggest seems to be very nice. 
>  
>

+1

>Can a selector in the lm provide a map? Can I use:
><traversal>    
>   <location src="{calculatedValue}"/>
></traversal>
>
>If the <traversal> selector returns null then the child will be ignored,
>otherwise it will use the {calculatedValue} that have been placed in the
>returning map of the selector. Is that possible?
>  
>

As I understand it, the LM can use any matchers or selectors available 
within Cocoon. So I guess that means the answer is yes, however, Tim is 
clearly more tuned in to this stuff so I'll leave it to you guys. 
Perhaps we should raise an issue to do this work at some point (seems to 
me like this is an ideal thing for Thorsten and Tim to tackle on a 
Forrest Tuesday if they both happen to be online at the same time).

Ross

Mime
View raw message