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
