On 6/6/05, Ross Gardler <[EMAIL PROTECTED]> 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
