forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: Locationmap now works for repositories
Date Mon, 06 Jun 2005 20:55:55 GMT
On 6/6/05, Ross Gardler <rgardler@apache.org> wrote:
> Tim Williams wrote:
> > I'm thinking my latest round of questions seem to have gotten lost...
> 
> Hmmmm. I typed a reply to this this morning. However, it doesn't appear
> in my sent box let alone the archives. I was offline at the time so
> maybe I clicked the wrong button and deleted it rather than "send later".
> 
> Oh well, here goes take 2...
> 
> 
> >>>>of course site.xml and tabs.xml which are handled differently than
> >>>>other content in xdocs.
> >>>
> >>>They are, but they need not be. This is something that needs to be
> >>>addressed. We should be able to get site.xml and tabs.xml from the
> >>>locationmap source too.
> >>
> >>I've got both of these working with locationmap now, let me know if
> >>that's preferable. This makes me wonder how "default" locationmaps
> >>will be set up.  Is there a concept of fallback locationmaps sorta
> >>like sitemaps do (e.g., allow project overrides to forrest
> >>pre-defined)?
> 
> The fallback position at present is to use the local file system. Is
> there a need for a more expressive fallback mechanism in the locationmap?
> 
> 
> >>I guess the question is: have you a grander design yet
> >>for how these things will actually work when it comes to *all*
> >>resources?
> 
> No, I only just figured out how they work, so no "grand designs" yet. I
> am hoping you can help me there.
> 
> >>It seems like this idea of overriding the forrest
> >>locationmap settings with the project locationmap settings seems
> >>necessary?
> 
> Can you give us a use case. I'm having trouble thinking of one.
> 
> >>>>Also, are you looking into expanding it for resource (graphics
> >>>>specifically) content too?
> >>>
> >>>Yes.
> 
> ...
> 
> >>Having looked at resources.xmap though,
> >>I agree, it is going to be a big job.  Before looking more at it
> >>though, I'd like to get your vision of how it should work.  Seems to
> >>me there needs to be some sort of forrest:locationmap and
> >>project:locationmap concepts in place first?  In other words as the
> >>locationmap concept is carried over to forrest assets as well as
> >>project assets, should each not have a overridable locationmap?
> 
> I'm not at all sure I am following you. Whilst it is a reasonably big
> job, I was thinking that all we need to do is provide the same kind of
> mechanism that we have provided for XML docs. That is, if we don't find
> it either locally, or via the plugins then we try and find it via the
> locationmap. If we still fail then we throw an error.
> 
> The only difference in this between current and future behaviour is the
> addition of the last check via the locationmap.
> 
> Am I missing something?

No., I was... again.  The "problem" that I saw stemmed from the poor
way that I made tabs.xml and site.xml use the locationmap.  I didn't
do it the sitemap way and so it lead me into a pretty dumb line of
thinking.  As you describe we *have* the fallback that I was trying to
get at but we're doing it through sitemaps already built in matching
order.  But because I simple replaced
<map:generate src="{project:content.xdocs}tabs.xml"/>
with
<map:generate src="{lm:tabs.xml}"/>
I got to thinking that there would be a need for a *default* app-level
locationmap pointing to the standard filesystem locations and then a
project-level locationmap that users would use to point elsewhere. 
Now that I read your email, took another look, and changed it to this
instead....
<map:select type="exists">
     <map:when test="{project:content.xdocs}tabs.xml">
          <map:generate src="{project:content.xdocs}tabs.xml"/>
     </map:when>
     <map:when test="{lm:tabs.xml}">
          <map:generate src="{lm:tabs.xml}"/>
      </map:when>
</map:select>
... I realize the error of my thinking and all is well.  Sorry for the
confusion, I'm learning, albeit slowly...
--tim

Mime
View raw message