Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
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
From: Thorsten Scherler <thorsten@apache.org>
To: twilliams@apache.org, forrest dev <dev@forrest.apache.org>
In-Reply-To: <4998884405082406541a5641f2@mail.gmail.com>
References: <20050819004415.38319.qmail@minotaur.apache.org>
	 <43059DD5.9050801@apache.org>
	 <1124459113.5100.17.camel@localhost.localdomain>
	 <430A07AF.3070202@apache.org>
	 <1124746287.5092.50.camel@localhost.localdomain>
	 <430C77F4.4040504@apache.org>  <4998884405082406541a5641f2@mail.gmail.com>
Content-Type: text/plain
Date: Wed, 24 Aug 2005 19:54:43 +0200
Message-Id: <1124906084.13647.13.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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:
<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?

TIA.

salu2
-- 
thorsten

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

--------------------------------------------------------------
Thorsten Scherler
Wyona Inc.  -  Open Source Content Management  -  Apache Lenya
http://www.wyona.com                   http://lenya.apache.org
thorsten.scherler@wyona.com                thorsten@apache.org