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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs