forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <twilli...@apache.org>
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
Date Wed, 24 Aug 2005 13:54:09 GMT
On 8/24/05, Ross Gardler <rgardler@apache.org> wrote:
> Thorsten Scherler wrote:
> > 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:
> >>>
> >>>
> >>>>thorsten@apache.org 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.
> 
> I think Tims response provides an example, I'm replying in that part of
> the thread.

Not exactly, there's one key difference as I understand it.  See below...

> > 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?
> 
> There is now the potential for a default forrest locatonmap which will
> import the user locationmap. Therefore Forrest defines the defaults and
> the user can define any extra. In other words it is the same as in your
> fallback resolver in which the defaults are defined in the resolver itself.

Actually, while there is the ability to "mount" a locationmap, I'm
having difficulties with the forrest-mounts-project-locationmap thing
at the moment.  When the project-level one doesn't exist, there are
problems.  "Assuming" the project-level locationmap exists would break
backwards compatibility.  Anyway, I'm having issues with it at the
moment.. I could send a separate description of that and don't want to
put this thread on a tangent.

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

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

--tim

Mime
View raw message