forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Fwd: 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.int
Date Fri, 26 Aug 2005 12:41:08 GMT
Not sure why that happened but my reply went personal instead of the list...
--tim

On 8/24/05, Thorsten Scherler <thorsten@apache.org> 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. :)
>
> > 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?

I missed this reply.  If I understand the question, the answer is kind
of.  All null-returning locations would be ignored except the last one
which would, not surprisingly, actually return null, meaning your
example above would also return null.  If this is done in the context
of a parent selector, then maybe it would get ignored -- I'd have to
check.

I'll admit that I didn't fully cook the [new traversal selector] idea
in my head before my fingers started typing it;)  I think this one
deserves more study and should be filed as a JIRA issue.

--tim

Mime
View raw message