Hi Alex, my notes below, sorry for the late response.
First, ObjectReference is supposed to have, as name, some sort of a string reference to the object inside the document (the ObjectReference has a DocumentReference as a parent). Now, since we didn't really agree what "string reference for the object" means (it could mean giving names to objects as we give to documents, it could mean some composed name of class name and index, etc), and this implied more discussions and design of the new model we decided to leave it like this, a "blank" position, unspecified name of object, where subclassers could implement their own object naming policy. Such a subclass is the IndexedObjectReference, which uses an object name made of class name and optional, index (if the index is missing it means 0). It's not in the platform because we didn't decide if this is the naming model for objects that we want (I can look for the mails). This approach works very well when the code that reads the references is the same that writes them (as the annotations case is), since it holds the sole responsibility of defining what an object name means. To be short, IndexedObjectReference is not an extension of the ObjectReference, as in containing more information, but just an implementation of the concept, based on the current model (objects are idd by classname and index), and in general a subclass (because it limits the forms that the name can take). On 29.07.2010 12:54, Alex Busenius wrote: > Hi devs, > > > It seems that currently there is no good way to manipulate XWiki objects > and properties in documents without depending on old core. > DocumentAccessBridge defines some methods for changing properties, but > they are very limited, in particular, there is no way to: > > * add a new property (except the first one) > * set a property of n-th object (getting it is possible) > * remove an object > * get the number of objects > > > Therefore I propose to add the following methods to DocumentAccessBridge: > > > // returns index of the new object > int addObject(ObjectReference obj) throws Exception; In the light of what I wrote above, what would the ObjectReference contain in this case? More precisely, what name of object would you use? > // returns false if there was no object, throws on access error > boolean removeObject(ObjectReference obj, int index) throws Exception; Index should not be here, object reference (as all references in general) should identify the item precisely, without the need of additional info. If it's an indexed object reference, the object name would contain the index as well. > // number of objects of the given class > int getObjectCount(ObjectReference obj); This does not make that much sense, since an object reference (as any reference) currently identifies an item and not a list of items, so this count would return 1 always. I think we discussed about this too in the mails (references referring lists), when we were still thinking that className and index should be part of the model, and that giving a class name would return a list, but with the currently adopted model it's no longer the case. > // returns index of the object that was modified, adds a new object if > // index is out of range > int setProperty(ObjectReference obj, int idx, String prop, Object val) > throws Exception; There is PropertyReference, which has the propertyName as name and an ObjectReference as a parent, so this would be: int setProperty(PropertyReference obj, Object val) throws Exception; > // just to have all needed methods taking object reference > Object getProperty(ObjectReference prop, int index, String propertyName); same, Object getProperty(PropertyReference prop); > > I've chosen ObjectReference because it contains (almost) all needed > information, including class name and document reference. No, the ObjectReference does not contain the classname, see the explanations above. IndexedObjectReference, indeed contains the classname at one point. > It would be > better to have the object index stored in the reference too, like in > org.xwiki.annotation.reference.IndexedObjectReference, but this class is > annotation-specific. We could decide to move it, but I would say, whenever the case allows it, to put ObjectReference in the APIs and only implement it with Indexed, so that API would be stable when we have indeed a model for the ObjectReference. It could cause mess for the caller, indeed, on changing the object name policy. Happy hacking, Anca > > I need those methods to store certificates in user profile, see > https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-signedscripts > > > WDYT? > > Thanks, > Alex > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
