forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
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 Mon, 22 Aug 2005 20:29:34 GMT
On 8/22/05, Ross Gardler <rgardler@apache.org> 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.
> 
> > 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.
> 
> 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.
> 
> 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?
> 
> Ross

Assuming I understand what this is doing, I don't immediately see why
this couldn't be done with either the locationmap or a
ResourceExistsSelector in the sitemap itself.  Below is a very rough
idea of what the locationmap version of this would be I think.  Maybe
there's something that the FallbackResolver is doing that I'm just not
"seeing" though?

    <map:match pattern="prepare.view.**">
      <map:generate src="{lm:prepare.view.{1}}"/>
      <map:transform src="resources/stylesheets/prepare.include.templates.xsl"/>
      <map:transform type="xinclude"/>
      <map:serialize type="xml"/>
    </map:match>
    
    <locator>
      <match pattern="prepare.view.**.*">
        <select>    
          <location src="{1}.{2}"/>
          <location src="{project:theme}{1}.{project:theme-ext}"/>
          <location src="{project:content.xdocs}{1}.{project:theme-ext}"/>
          <location src="{defaults:view-themes}...
          <location src="{defaults:theme}...
        </select>
      </match>
    </locator>

--tim

Mime
View raw message