Jack Moffitt <jack@chesspark.com> writes:
I think it's fine to support both approaches. I think my original complaint was actually worded that way. The issue is that there may not be a path from root to a child. Ie, /some/path/to/proxy exists, but /some/path doesn't. It takes some jiggering to set that up right now, because you have to make dummy nodes along the path. Which works, but is not as optimal for this use case.
Oh, one follow-on to my last response. While I've been referring to getChild while talking about the traversal, technically its getChildWithDefault that is being used with standard Resource instances. This gives precedence to explicit child resource instances (added with putChild), falling back to getChild if no matching static child has been added. So in terms of a custom mapping Resource, you could install this as the Root of your site, implement the custom getChild mapping, and still use putChild to install some static paths that didn't use the new mapping. In such a case, getChild would only be getting called if no static children were found, so again, the fact that it was being called at all would imply that you should fall back to your custom mapping. The one case you would probably have to check for would be a getChild lookup for "", which should render the actual site root page contents, unless you wanted to delegate that to some other resource by using putChild with a path of "". -- David