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.internal.view/resources/stylesheets/ whiteboard/plugi...)
Date Mon, 22 Aug 2005 21:31:26 GMT
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:
> > 
> >> 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/
> >>
> >>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
<match pattern="rewriteDemo/**">
 <location src="{1}.fv" />
<!--How can you have dir fallbacks without defining the dir structure
 <location src="{dir}{1}.fv" />
 <location src="" />

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.

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?

> > The action reads a location (uri) and scans it whether a file exist. If
> > not it will scan for any project specific fallbacks that may exist (see
> > above). After this it scans further for default fallbacks (see
> > Actually in above code we now can easily
> > instance the SourceTypeAction [1] and implement "content aware
> > views" (FOR-621). 
> > 
> > Can the loactionmap help me with all that?
> Yes, at least to the first part, the second part needs work, as with the 
> fallback resolver.

No, the first cannot be solved with the lm. *ONLY* if you define the
whole fallback list (like stated above).

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

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

View raw message