thanks for the quick and extensive answer :)
we are currently trying to make our store binding enabled. It occurs to me that we will not only have to adapt our own store, but also have to replace org.apache.slide.store.StandardStore.
Why that?
This is quite a drastic change as this class implements one of Slides most prominent features: delegation of requests to several different services or stores.
This makes me wonder, do you still use all the central classes for your Tamino store? Am I getting all this wrong, in the first place? Could you please provide me with some more hints?
Indeed, we use an own extension (say, "ParentStore") of StandardStore. To activate it, we reference it in the store configuration (Domain.xml) ... something like:
<store name="mystore" classname="com.mycompany.ParentStore"> <nodestore classname="slidestore.reference.MemoryDescriptorsStore" /> <contentstore classname="slidestore.reference.FileContentStore" /> <securitystore> <reference store="nodestore" /> </securitystore> ... and so on ... </store>
But ParentStore is not a big deal. Most important is to overwrite useBinding():
public boolean useBinding() { return true; }
That's what we have done, but we get problems with certain methods that check for the uri of ObjectNode which is null in a binding enabled context. One example is ObjectNode.validate(String expectedUri) which is called by StandardStore.retrieveObject. Also NodePermission needs the uri of an object. What should we pass over to it? The URI or the UURI. If it was the UURI we need to fix this in StandardStore as well.
Only replacing methods that cause trouble (the ones named above and some more) in StandardStore seemed to be bad practice to me, so I thought I'd better replace StandardStore as a whole. That in turn occured to me too big a change. I thought such changes might better be incorporated into the default StandardStore not into my local copy here.
Maybe, again, I got things wrong?
The main work is in the child stores (mainly the descriptors store).
The main issues are: 1) use a non-hierarchical unique URI (UURI) to internally identify resources 2) use a fix UURI for the root object of each store (corresponding to the scope of the store) 3) store bindings and parent-bindings of ObjectNode (instead of storing children) 2) implement a resolve() method which takes an URI and returns the associated UURI
All the binding-relevant information should be available in the ObjectNode. In particular, the algorithm for the resolve() method goes something like this:
- input: URI=/files/foo/bar/a.txt - retrieve the ObjectNode "o1" for the root of the store (suppose it is /files with fix uuri1) - uuri2 = o1.getBindingUuri("foo"); - get ObjectNode "o2" with UURI=uuri2 - uuri3 = o2.getBindingUuri("bar"); - get ObjectNode "o3" with UURI=uuri3 - return o3.getBindingUuri("a.txt");
Also, a binding-enabled store uses the following contructor of ObjectNode (of course through e.g. SubjectNode) when objects are being retrieved:
/** * Contructor to be used by stores supporting binding. */ public ObjectNode(String uuri, Vector bindings, Vector parentBindings, Vector links) { this(); this.uuri = uuri; this.bindings = new BindingList(bindings); this.parentBindings = new ParentBindingList(parentBindings); this.links = links; }
These things about the child store are really helpful to me :) I will try them out!
Please, let me know if you still have problems or questions.
Thanks again for helping
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
