forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Merging locationmap with trunk [was: Merging views with trunk]
Date Fri, 01 Jul 2005 02:44:20 GMT
> Now to the road-map I see for views and the lm-branch:
> 1) Fix all issues with the lm in the lm-branch (there are just minor
> ones that I am aware of)
> 2) merge all lm related stuff with trunk (branch->trunk)
> 3) merge all view changes into whiteboard trunk (branch->trunk) That
> step is and should be independent from step 2, it is only after this
> step because we now have 1 contract that is based on the lm stuff.
> 4) *Stop* and freeze developing the view plugins in trunk!!!
> 5) Open view-branch and start to integrate views into the core

I think the only issue with the locationmap branch that I can find is
FOR-554.  With the suggested workaround that I describe below, I think
we can take that off the list for now and allow the branch to go ahead
and be merged.  I don't want to be too pushy here, but locationmap
branch already seems to have gotten a bad rep for being away from
trunk too long so I think anything we can do to let others take
advantage of the goodness that's in this branch, the better off we'll
be.

Here's my proposal for FOR-554.  Essentially, do an exists check for
locationmap resolution, then as an otherwise, go back to the default
location and let the SourceNotFoundException come from there.  That
will get an understandable error message at least.

For example, what we have now:
<map:select type="exists">
  <map:when test="{project:content.xdocs}tabs.xml">
    <map:generate src="{project:content.xdocs}tabs.xml"/>
  </map:when>
  <map:otherwise>
    <map:generate src="{lm:tabs.xml}"/>
  </map:otherwise>
</map:select>
since the FileGenerator resolves an empty string (what's returned from
a non-matching hint in the locationmapmodule) to the root context, it
gives us an AccessDenied exception rather than a sourcenotfound
exception. What I think we should do as the workaround is:
<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:otherwise>
    <map:generate src="{project:content.xdocs}tabs.xml"/>
  </map:otherwise>
</map:select>
This, while clearly not the best answer, would give users a reasonable
sourcenotfound error message.

There are two things leading me to this answer:
1) I believe FOR-554 is ultimately a cocoon bug that should be fixed
and so anything we do would be a workaround.

2) I've come to understand that we need a more robust location
resolution error handling capability (as described in another post
that apparently wasn't well received).  It basically said that we
should ultimately be reporting in error messages all locations that
were searched for a resource rather than whatever happens to be in the
"otherwise" clause.

Thoughts?

This, of course, also assumes that everyone agreed that for now we
should revert the fresh-site dependency on views until they're ready
to come out of whiteboard.

Anyway, as I said, I don't mean to come across pushy on this
locationmap branch but I think it's ready to merge and shouldn't grow
moldy.  If this is an acceptable solution, then I'll submit the
appropriate patch for tabs, site, and resource locationmap resolution.

Thanks,
--tim

Mime
View raw message