On 2012-05-15 20:39, Jukka Zitting wrote:
Hi,
On Tue, May 15, 2012 at 7:58 PM, Julian Reschke<[email protected]> wrote:
This isn't sufficient; there are API signatures where even a "[1]" on the
final path segment is forbidden, such as when creating new nodes.
We can either hack these restrictions into NodeImpl, SessionImpl and
friends, or extend the path mapper to optionally check.
Couldn't we just pass them as is down to oak-core, where such names
can be rejected as invalid by a commit hook? Or if an exception is
required before save(), I'd rather have such checks explicitly in
NodeImpl& friends instead of overloading the path mapper with extra
responsibilities.
So you want it either higher in the stack or lower but not here? :-)
"higher" is tricky, because to do it properly, you need to parse the
path. I thought we don't want to do that more than once.
"lower" might actually work.
IMO it should be possible for the path mapper to be a no-op whenever
no session-local namespace re-mappings are in place. In such cases as
long as a path doesn't contain any {expanded}names, the mapper
shouldn't need to do any other parsing and can return the exact same
path string instance it received.
True; we just need to add index processing to that list.
A separate path resolver (see my other post about the mapper/resolver
distinction) should take care of evaluating the mapped path string in
a specific context. Such resolution would for example involve finding
the parent node of the relative path provided to an addNode() call.
In cases like addNode(), neither the path mapper nor the resolver
should have to worry about rules like whether an index is allowed in
the last path element. Instead the relevant code should look something
like this:
// Map and validate the last name segment of the given path
String jcrName = PathUtils.getName(relPath);
String oakName = nameMapper.getOakName(jcrName);
if (oakName == null || isInvalidNodeName(oakName)) {
throw new RepositoryException("Invalid node name: " + relPath);
}
// Map and resolve the relative path leading to the new node
String jcrPath = PathUtils.getParentPath(relPath);
String oakPath = ssessionDelegate.getOakPathOrThrowNotFound(jcrPath);
NodeDelegate parent = dlg.getChild(oakPath);
if (parent == null) {
throw new PathNotFoundException(relPath);
}
Yes, we can make this work, but it essentially means that the path is
parsed twice.
Best regards, Julian
