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:
> >
> >>[EMAIL PROTECTED] 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.
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
> > FallbackResolverAction.java). 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 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.
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
