forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
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 Wed, 24 Aug 2005 17:54:43 GMT
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. :) 

> 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. 

Can a selector in the lm provide a map? Can I use:
   <location src="{calculatedValue}"/>

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?



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

Thorsten Scherler
Wyona Inc.  -  Open Source Content Management  -  Apache Lenya               

View raw message