You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/06/05 02:10:38 UTC
Locationmap now works for repositories
Well Zeph, my son, had a nightmare so I'm wide awake in the middle of
the night (again), as a result I spent some time on the Locationmap branch.
The good news is that it now works for generating files from a
repository. I've created a demo within fresh-site (in the locationmap
branch). The demo shows how to do link rewriting and how to retrieve
content from a remote repository without having to encode the location
of the repository or the path to the file within it in the Forrest site URL.
This is pretty powerful stuff. It means we can create single sites from
multiple repositories, whether they be local, remote or a combination of
the two.
Next stage is for me to make the Daisy plugin work with the locationmap.
I can't remember who wrote the locationmap code it was so long ago. I
wish I had had the itch to play with it a long time ago. In my opinion
this is going to be another key feature of Forrest.
The future of Forrest looks bright:
- Plugins
- Views
- Locationmaps
this is killer stuff!
Ross
Re: Locationmap now works for repositories
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>I can't remember who wrote the locationmap code it was so long ago.
>
> It was Unico Hommes, a Cocoon developer.
> svn log java/org/apache/forrest/locationmap/lm/LocationMap.java
Yes, kudos to him.
I had been thinking and talking about it for a long time but, as my
usual ;-P, i had not done anything concrete. Then Unico came along and
simply wrote it, amazing me by the reuse of the sitemap code itself.
The power of OpenSource :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Locationmap now works for repositories
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>I can't remember who wrote the locationmap code it was so long ago.
>
>
> It was Unico Hommes, a Cocoon developer.
> svn log java/org/apache/forrest/locationmap/lm/LocationMap.java
Unico - Thnk you!
I'm so sorry it has languished in our SVN for so long, I think that it
was just too far ahead of us (me?) at the time.
Ross
Re: Locationmap now works for repositories
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
>
> I can't remember who wrote the locationmap code it was so long ago.
It was Unico Hommes, a Cocoon developer.
svn log java/org/apache/forrest/locationmap/lm/LocationMap.java
--David
Re: Locationmap now works for repositories
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> I should just add that a gap in my understanding is the relationship
> between LocationMapModule and SourceExistsSelector.
Basically an input-module (which is what the LocationmapModule is)
provides an additional sitemap variable. In this case {lm:...} When the
sitemap processor encounters such a variable it uses the locationmap
module to work out the value of that variiable, this, as you now know,
comes from the locationamp.xml file (in our case).
There is no direct connection between the SourceExistsSelector and the
LocationMapModule.
For more see the cocoon docs at
http://cocoon.apache.org/2.1/userdocs/concepts/modules.html
Ross
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
On 6/7/05, Tim Williams <wi...@gmail.com> wrote:
> On 6/7/05, Ross Gardler <rg...@apache.org> wrote:
> > Tim Williams wrote:
> > > On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
> > >
> > >>Tim Williams wrote:
> > >>
> > >>>On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
> > >>>
> > >>>
> > >>>>Tim Williams wrote:
> > >>
> > >>...
> > >>
> > >>
> > >>><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>
> > >>
> > >>This is interesting. Have you tested what happens when {lm:tabs.xml}
> > >>does not point to anything useful? That is, does the second <map:when> work?
> > >
> > >
> > > :( Sadly, no. It looks like {lm:tabs.xml} always evaluates to
> > > existing. Are locationmaps not usable in an exists selector for some
> > > reason?
> > >
> >
> > My guess is (there's another disclaimer, I haven't tested this yet)...
> >
> > Since you are mapping the {lm:tabs.xml} to a http request a document is
> > always returned. It may be a 404 error, but it is still a document. To
> > confirm this we would need to look at the generator code and, if
> > necessary detect error conditions from the various repository types.
>
> The problem or at least a symptom appears to be with the resolver
> inside the select method of SourceExistsSelector. Here's my
> rationale:
>
> o) LocationMapModule appears to properly be responding with null if a
> particular hint is not found.
>
> o) The empty string comes into SourceExistsSelector and for some weird
> reason the resolver resolves it to
> "file:/C:/src/apache-forrest-7-branch/main/webapp/" (for me, but you
> get the idea).
>
> o) Obviously calling src.exists() on the above location returns true
> causing the map:when to always evaluate to true even when no hint is
> found in the locationmap.
>
> I've got a temporary hack in place by testing for an empty uri
> parameter immediately before it even gets to the resolver. This gets
> me the behaviour I would expect in an exists selector test but I'm
> thinking it'd be best if someone who knows exactly how the
> resolver/SourceExistsSelector works took a look at it. In the mean
> time, I could use my little hack to keep moving.
>
> Make sense?
I should just add that a gap in my understanding is the relationship
between LocationMapModule and SourceExistsSelector. I assume somehow
the resolver is aware of LocationMapModule because it implements
InputModule. If that's truly the case, it'd also be worth noting that
a hint that doesn't exist does properly come out of getAttributes().
--tim
Re: Locationmap now works for repositories
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 6/7/05, Ross Gardler <rg...@apache.org> wrote:
...
>>What you appear to have tested is what happens if the locationmap does
>>not have a match for the resource.
>
>
> Right, I've now tested:
> a) If the "hint" does exist in locationmap.xml --> Works as expected
> b) If the "hint" does exist in locationmap.xml but the location src is
> junk --> fails in the same way that it would if
> {project.content.xdocs}tabs.xml didn't exist.
> c) If the "hint" does not exist in locationmap.xml --> Works as
> expected once SourceExistSelector is hacked.
OK, can you raise an issue for (c) with a snippet showing your workaround.
>>>o) The empty string comes into SourceExistsSelector and for some weird
>>>reason the resolver resolves it to
>>>"file:/C:/src/apache-forrest-7-branch/main/webapp/" (for me, but you
>>>get the idea).
>>
>>This is not weird if one knows the internals of Cocoon. This location is
>> the context root for your installation of Cocoon. This is were
>>everything is relative to. So, since we have a null from the locaitonmap
>>module we are looking in the root.
>
>
> This may seem reasonable to Cocooners but I still think such behaviour
> is non-intuitive.
I didn't mean we should leave it as is, only that it makes sense. The
perils of working in an alpha branch I'm afraid.
>>Could you provide a patch to the locationmap branch for the stuff that
>>you have done so that we can both see the same code.
>
>
> Sure, post it to the jira issue or send to the list?
Patches should always go in Jira they don;t get lost there.
> It'll take some
> time because I'm going to have to revert everything and reapply select
> changes locally so that I don't goof anything up.
No problem, take all the time you need. Your input so far has been
valuable enough, I just want to make sure we capture it in a more
permanent memory than my own and the list archives.
Ross
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
On 6/7/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > On 6/7/05, Ross Gardler <rg...@apache.org> wrote:
> >
> >>Tim Williams wrote:
> >>
> >>>On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
> >>>
> >>>
> >>>>Tim Williams wrote:
> >>>>
> >>>>
> >>>>>On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Tim Williams wrote:
> >>>>
> >>>>...
> >>>>
> >>>>
> >>>>
> >>>>><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>
> >>>>
> >>>>This is interesting. Have you tested what happens when {lm:tabs.xml}
> >>>>does not point to anything useful? That is, does the second <map:when> work?
> >>>
> >>>
> >>>:( Sadly, no. It looks like {lm:tabs.xml} always evaluates to
> >>>existing. Are locationmaps not usable in an exists selector for some
> >>>reason?
> >>>
> >>
> >>My guess is (there's another disclaimer, I haven't tested this yet)...
> >>
> >>Since you are mapping the {lm:tabs.xml} to a http request a document is
> >>always returned. It may be a 404 error, but it is still a document. To
> >>confirm this we would need to look at the generator code and, if
> >>necessary detect error conditions from the various repository types.
> >
> >
> > The problem or at least a symptom appears to be with the resolver
> > inside the select method of SourceExistsSelector. Here's my
> > rationale:
> >
> > o) LocationMapModule appears to properly be responding with null if a
> > particular hint is not found.
>
> This is different from what I intended to ask above. I meant if the hint
> *does* resolve to something sensible in the locationmap (e.g.
> http://slide.domain.org:8080/page.xml) what happens.
It works fine then.
> What you appear to have tested is what happens if the locationmap does
> not have a match for the resource.
Right, I've now tested:
a) If the "hint" does exist in locationmap.xml --> Works as expected
b) If the "hint" does exist in locationmap.xml but the location src is
junk --> fails in the same way that it would if
{project.content.xdocs}tabs.xml didn't exist.
c) If the "hint" does not exist in locationmap.xml --> Works as
expected once SourceExistSelector is hacked.
> > o) The empty string comes into SourceExistsSelector and for some weird
> > reason the resolver resolves it to
> > "file:/C:/src/apache-forrest-7-branch/main/webapp/" (for me, but you
> > get the idea).
>
> This is not weird if one knows the internals of Cocoon. This location is
> the context root for your installation of Cocoon. This is were
> everything is relative to. So, since we have a null from the locaitonmap
> module we are looking in the root.
This may seem reasonable to Cocooners but I still think such behaviour
is non-intuitive.
> > o) Obviously calling src.exists() on the above location returns true
> > causing the map:when to always evaluate to true even when no hint is
> > found in the locationmap.
>
> This is an interesting point...
>
> > I've got a temporary hack in place by testing for an empty uri
> > parameter immediately before it even gets to the resolver. This gets
> > me the behaviour I would expect in an exists selector test
>
> Does it get the behaviour you expect. Have you tried having a valid
> match in the locationmap but not having the resource present at
> indicated location?
It is what I expect. That's my test "b" above.
> > but I'm
> > thinking it'd be best if someone who knows exactly how the
> > resolver/SourceExistsSelector works took a look at it. In the mean
> > time, I could use my little hack to keep moving.
>
> I would have thought we can just check for a null in the
> SourceExistsSelector. However, this is a Cocoon component not a Forrest
> one so we need to take this to Cocoon. I don't have the time to follow
> it through just yet, maybe next week.
Right now a null test didn't work so I'm checking for null or "".
Somewhere along the line that null is passed in as a "" but I don't
know where/how yet.
> Could you provide a patch to the locationmap branch for the stuff that
> you have done so that we can both see the same code.
Sure, post it to the jira issue or send to the list? It'll take some
time because I'm going to have to revert everything and reapply select
changes locally so that I don't goof anything up.
--tim
Re: Locationmap now works for repositories
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 6/7/05, Ross Gardler <rg...@apache.org> wrote:
>
>>Tim Williams wrote:
>>
>>>On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
>>>
>>>
>>>>Tim Williams wrote:
>>>>
>>>>
>>>>>On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Tim Williams wrote:
>>>>
>>>>...
>>>>
>>>>
>>>>
>>>>><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>
>>>>
>>>>This is interesting. Have you tested what happens when {lm:tabs.xml}
>>>>does not point to anything useful? That is, does the second <map:when> work?
>>>
>>>
>>>:( Sadly, no. It looks like {lm:tabs.xml} always evaluates to
>>>existing. Are locationmaps not usable in an exists selector for some
>>>reason?
>>>
>>
>>My guess is (there's another disclaimer, I haven't tested this yet)...
>>
>>Since you are mapping the {lm:tabs.xml} to a http request a document is
>>always returned. It may be a 404 error, but it is still a document. To
>>confirm this we would need to look at the generator code and, if
>>necessary detect error conditions from the various repository types.
>
>
> The problem or at least a symptom appears to be with the resolver
> inside the select method of SourceExistsSelector. Here's my
> rationale:
>
> o) LocationMapModule appears to properly be responding with null if a
> particular hint is not found.
This is different from what I intended to ask above. I meant if the hint
*does* resolve to something sensible in the locationmap (e.g.
http://slide.domain.org:8080/page.xml) what happens.
What you appear to have tested is what happens if the locationmap does
not have a match for the resource.
> o) The empty string comes into SourceExistsSelector and for some weird
> reason the resolver resolves it to
> "file:/C:/src/apache-forrest-7-branch/main/webapp/" (for me, but you
> get the idea).
This is not weird if one knows the internals of Cocoon. This location is
the context root for your installation of Cocoon. This is were
everything is relative to. So, since we have a null from the locaitonmap
module we are looking in the root.
> o) Obviously calling src.exists() on the above location returns true
> causing the map:when to always evaluate to true even when no hint is
> found in the locationmap.
This is an interesting point...
> I've got a temporary hack in place by testing for an empty uri
> parameter immediately before it even gets to the resolver. This gets
> me the behaviour I would expect in an exists selector test
Does it get the behaviour you expect. Have you tried having a valid
match in the locationmap but not having the resource present at
indicated location?
> but I'm
> thinking it'd be best if someone who knows exactly how the
> resolver/SourceExistsSelector works took a look at it. In the mean
> time, I could use my little hack to keep moving.
I would have thought we can just check for a null in the
SourceExistsSelector. However, this is a Cocoon component not a Forrest
one so we need to take this to Cocoon. I don't have the time to follow
it through just yet, maybe next week.
Could you provide a patch to the locationmap branch for the stuff that
you have done so that we can both see the same code.
> Make sense?
It certainly does, thanks.
Ross
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
On 6/7/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
> >
> >>Tim Williams wrote:
> >>
> >>>On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
> >>>
> >>>
> >>>>Tim Williams wrote:
> >>
> >>...
> >>
> >>
> >>><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>
> >>
> >>This is interesting. Have you tested what happens when {lm:tabs.xml}
> >>does not point to anything useful? That is, does the second <map:when> work?
> >
> >
> > :( Sadly, no. It looks like {lm:tabs.xml} always evaluates to
> > existing. Are locationmaps not usable in an exists selector for some
> > reason?
> >
>
> My guess is (there's another disclaimer, I haven't tested this yet)...
>
> Since you are mapping the {lm:tabs.xml} to a http request a document is
> always returned. It may be a 404 error, but it is still a document. To
> confirm this we would need to look at the generator code and, if
> necessary detect error conditions from the various repository types.
The problem or at least a symptom appears to be with the resolver
inside the select method of SourceExistsSelector. Here's my
rationale:
o) LocationMapModule appears to properly be responding with null if a
particular hint is not found.
o) The empty string comes into SourceExistsSelector and for some weird
reason the resolver resolves it to
"file:/C:/src/apache-forrest-7-branch/main/webapp/" (for me, but you
get the idea).
o) Obviously calling src.exists() on the above location returns true
causing the map:when to always evaluate to true even when no hint is
found in the locationmap.
I've got a temporary hack in place by testing for an empty uri
parameter immediately before it even gets to the resolver. This gets
me the behaviour I would expect in an exists selector test but I'm
thinking it'd be best if someone who knows exactly how the
resolver/SourceExistsSelector works took a look at it. In the mean
time, I could use my little hack to keep moving.
Make sense?
--tim
Re: Locationmap now works for repositories
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
>
>>Tim Williams wrote:
>>
>>>On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
>>>
>>>
>>>>Tim Williams wrote:
>>
>>...
>>
>>
>>><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>
>>
>>This is interesting. Have you tested what happens when {lm:tabs.xml}
>>does not point to anything useful? That is, does the second <map:when> work?
>
>
> :( Sadly, no. It looks like {lm:tabs.xml} always evaluates to
> existing. Are locationmaps not usable in an exists selector for some
> reason?
>
My guess is (there's another disclaimer, I haven't tested this yet)...
Since you are mapping the {lm:tabs.xml} to a http request a document is
always returned. It may be a 404 error, but it is still a document. To
confirm this we would need to look at the generator code and, if
necessary detect error conditions from the various repository types.
Ross
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
> >
> >>Tim Williams wrote:
>
> ...
>
> > <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>
>
> This is interesting. Have you tested what happens when {lm:tabs.xml}
> does not point to anything useful? That is, does the second <map:when> work?
:( Sadly, no. It looks like {lm:tabs.xml} always evaluates to
existing. Are locationmaps not usable in an exists selector for some
reason?
--tim
Re: Locationmap now works for repositories
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 6/6/05, Ross Gardler <rg...@apache.org> wrote:
>
>>Tim Williams wrote:
...
> <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>
This is interesting. Have you tested what happens when {lm:tabs.xml}
does not point to anything useful? That is, does the second <map:when> work?
Ross
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
On 6/6/05, Ross Gardler <rg...@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
Re: Locationmap now works for repositories
Posted by Ross Gardler <rg...@apache.org>.
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?
Ross
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
I'm thinking my latest round of questions seem to have gotten lost...
The ones with a single ">" in front.
--tim
...
> > > 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)? I guess the question is: have you a grander design yet
> for how these things will actually work when it comes to *all*
> resources? It seems like this idea of overriding the forrest
> locationmap settings with the project locationmap settings seems
> necessary?
> > > Also, are you looking into expanding it for resource (graphics
> > > specifically) content too?
> >
> > Yes. My goal is to be able to use the locationmap for everything.
> > However, this is a pretty big job and could introduce many unexpected
> > bugs so would need lots of testing. As you get more comfortable with
> > sitemaps and the like, perhaps you can help (hint resources are handled
> > by the resources.xmap file).
>
> Clearly there's a lot left to learn but I'm no longer as intimidated
> with the *xmaps -- frightening as it may be, they're actually
> beginning to make sense now. 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?
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
On 6/5/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > On 6/5/05, Ross Gardler <rg...@apache.org> wrote:
> >
> >>Tim Williams wrote:
> >>
> >>>After reading, studying *.xmap, and re-reading, I think I'm
> >>>understanding this a bit better. My question is should the
> >>>locationmap match be moved earlier in the pipeline? I got the
> >>>behaviour I would have expected by moving it immediately before all of
> >>>the i18n matches for regular source content.
> >>
> >>No. If it were moved to before the i18n match for *.xml files it would
> >>prevent that code from working since the first match in which the
> >>generator is executed is the *only* match that will run.
> >>
> >>Is there a reason why you want to move it earlier?
> >
> >
> > Because a match in xdocs takes precedence over locationmap right now.
>
> Yes, this is by design. The assumption is that it is more efficient to
> use a local file than a remote one and so the local file takes
> precedence if it is present. Besides, if we don't give priority to local
> files it will break backward compatability, which we cannot do.
Right, sounds good. I guess i jumped the gun a bit in thinking it a
bug -- I'd spent a couple hours figuring it out and got overly pleased
with myself i guess:(
> In the final version of the Locationmap system it is likely that *all*
> files will be served via the locationmap which will have a default of
> serving from the local filesystem. However, I'm not sure how to do this
> without breaking the i18N stuff, at least not yet.
>
> Note that the locationmap is not actually scheduled until 0.9. It is
> likely that it will first be added as an alpha feature into 0.8-dev once
> 0.7 is released. This will have to go to a community vote though.
> ...
>
> > 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)? I guess the question is: have you a grander design yet
for how these things will actually work when it comes to *all*
resources? It seems like this idea of overriding the forrest
locationmap settings with the project locationmap settings seems
necessary?
> > Also, are you looking into expanding it for resource (graphics
> > specifically) content too?
>
> Yes. My goal is to be able to use the locationmap for everything.
> However, this is a pretty big job and could introduce many unexpected
> bugs so would need lots of testing. As you get more comfortable with
> sitemaps and the like, perhaps you can help (hint resources are handled
> by the resources.xmap file).
Clearly there's a lot left to learn but I'm no longer as intimidated
with the *xmaps -- frightening as it may be, they're actually
beginning to make sense now. 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?
--tim
Re: Locationmap now works for repositories
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 6/5/05, Ross Gardler <rg...@apache.org> wrote:
>
>>Tim Williams wrote:
>>
>>>After reading, studying *.xmap, and re-reading, I think I'm
>>>understanding this a bit better. My question is should the
>>>locationmap match be moved earlier in the pipeline? I got the
>>>behaviour I would have expected by moving it immediately before all of
>>>the i18n matches for regular source content.
>>
>>No. If it were moved to before the i18n match for *.xml files it would
>>prevent that code from working since the first match in which the
>>generator is executed is the *only* match that will run.
>>
>>Is there a reason why you want to move it earlier?
>
>
> Because a match in xdocs takes precedence over locationmap right now.
Yes, this is by design. The assumption is that it is more efficient to
use a local file than a remote one and so the local file takes
precedence if it is present. Besides, if we don't give priority to local
files it will break backward compatability, which we cannot do.
In the final version of the Locationmap system it is likely that *all*
files will be served via the locationmap which will have a default of
serving from the local filesystem. However, I'm not sure how to do this
without breaking the i18N stuff, at least not yet.
Note that the locationmap is not actually scheduled until 0.9. It is
likely that it will first be added as an alpha feature into 0.8-dev once
0.7 is released. This will have to go to a community vote though.
...
> 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.
>
> Also, are you looking into expanding it for resource (graphics
> specifically) content too?
Yes. My goal is to be able to use the locationmap for everything.
However, this is a pretty big job and could introduce many unexpected
bugs so would need lots of testing. As you get more comfortable with
sitemaps and the like, perhaps you can help (hint resources are handled
by the resources.xmap file).
Ross
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
On 6/5/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > After reading, studying *.xmap, and re-reading, I think I'm
> > understanding this a bit better. My question is should the
> > locationmap match be moved earlier in the pipeline? I got the
> > behaviour I would have expected by moving it immediately before all of
> > the i18n matches for regular source content.
>
> No. If it were moved to before the i18n match for *.xml files it would
> prevent that code from working since the first match in which the
> generator is executed is the *only* match that will run.
>
> Is there a reason why you want to move it earlier?
Because a match in xdocs takes precedence over locationmap right now.
I guess it only matters because I was using the samples directory to
play around with Slide and I have a samples directory in both Slide
and xdocs -- xdocs always wins. I guess I didn't have to worry
about the other code running because I'm essentially using the
locationmap to point everything in xdocs to Slide right now. Except
of course site.xml and tabs.xml which are handled differently than
other content in xdocs.
Also, are you looking into expanding it for resource (graphics
specifically) content too?
--tim
Re: Locationmap now works for repositories
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> After reading, studying *.xmap, and re-reading, I think I'm
> understanding this a bit better. My question is should the
> locationmap match be moved earlier in the pipeline? I got the
> behaviour I would have expected by moving it immediately before all of
> the i18n matches for regular source content.
No. If it were moved to before the i18n match for *.xml files it would
prevent that code from working since the first match in which the
generator is executed is the *only* match that will run.
Is there a reason why you want to move it earlier?
Ross
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
After reading, studying *.xmap, and re-reading, I think I'm
understanding this a bit better. My question is should the
locationmap match be moved earlier in the pipeline? I got the
behaviour I would have expected by moving it immediately before all of
the i18n matches for regular source content.
--tim
On 6/4/05, Tim Williams <wi...@gmail.com> wrote:
> Thanks Ross this is great stuff. It seems that locationmap'ed content
> is a secondary priority in terms of retrieving content. For a real
> world scenario it likely won't matter but for folks testing this out
> like me, if there's matching content in the xdocs it seems that it is
> retrieved first, then if it doesn't exist, the locationmap matches are
> used.
>
> --tim
>
> On 6/4/05, Ross Gardler <rg...@apache.org> wrote:
> > Well Zeph, my son, had a nightmare so I'm wide awake in the middle of
> > the night (again), as a result I spent some time on the Locationmap branch.
> >
> > The good news is that it now works for generating files from a
> > repository. I've created a demo within fresh-site (in the locationmap
> > branch). The demo shows how to do link rewriting and how to retrieve
> > content from a remote repository without having to encode the location
> > of the repository or the path to the file within it in the Forrest site URL.
> >
> > This is pretty powerful stuff. It means we can create single sites from
> > multiple repositories, whether they be local, remote or a combination of
> > the two.
> >
> > Next stage is for me to make the Daisy plugin work with the locationmap.
> >
> > I can't remember who wrote the locationmap code it was so long ago. I
> > wish I had had the itch to play with it a long time ago. In my opinion
> > this is going to be another key feature of Forrest.
> >
> > The future of Forrest looks bright:
> >
> > - Plugins
> > - Views
> > - Locationmaps
> >
> > this is killer stuff!
> >
> > Ross
> >
>
Re: Locationmap now works for repositories
Posted by Tim Williams <wi...@gmail.com>.
Thanks Ross this is great stuff. It seems that locationmap'ed content
is a secondary priority in terms of retrieving content. For a real
world scenario it likely won't matter but for folks testing this out
like me, if there's matching content in the xdocs it seems that it is
retrieved first, then if it doesn't exist, the locationmap matches are
used.
--tim
On 6/4/05, Ross Gardler <rg...@apache.org> wrote:
> Well Zeph, my son, had a nightmare so I'm wide awake in the middle of
> the night (again), as a result I spent some time on the Locationmap branch.
>
> The good news is that it now works for generating files from a
> repository. I've created a demo within fresh-site (in the locationmap
> branch). The demo shows how to do link rewriting and how to retrieve
> content from a remote repository without having to encode the location
> of the repository or the path to the file within it in the Forrest site URL.
>
> This is pretty powerful stuff. It means we can create single sites from
> multiple repositories, whether they be local, remote or a combination of
> the two.
>
> Next stage is for me to make the Daisy plugin work with the locationmap.
>
> I can't remember who wrote the locationmap code it was so long ago. I
> wish I had had the itch to play with it a long time ago. In my opinion
> this is going to be another key feature of Forrest.
>
> The future of Forrest looks bright:
>
> - Plugins
> - Views
> - Locationmaps
>
> this is killer stuff!
>
> Ross
>