10 Jan
2010
10 Jan
'10
8:45 p.m.
On Jan 10, 2010, at 4:23 PM, Sergiu Dumitriu wrote:
On 01/10/2010 03:12 PM, Vincent Massol wrote:
Actually it's used in a lot of places in the old code... I've fixed the ones
I've found and I keep finding new ones. The latest example:
public XWikiDocument copyDocument(String newDocumentName, XWikiContext context) throws
XWikiException
{
loadAttachments(context);
loadArchive(context);
XWikiDocument newdoc = (XWikiDocument) clone();
newdoc.setOriginalDocument(null);
newdoc.setFullName(newDocumentName, context);
newdoc.setContentDirty(true);
newdoc.getxWikiClass().setName(newDocumentName);
Map<String, Vector<BaseObject>> objectclasses =
newdoc.getxWikiObjects();
if (objectclasses != null) {
for (Vector<BaseObject> objects : objectclasses.values()) {
if (objects != null) {
for (BaseObject object : objects) {
if (object != null) {
object.setName(newDocumentName);
// Since GUIDs are supposed to be Unique, although this object
holds the same data, it is
// not
// exactly the same object, so it should have a different
identifier.
object.setGuid(UUID.randomUUID().toString());
}
}
}
}
}
XWikiDocumentArchive archive = newdoc.getDocumentArchive();
if (archive != null) {
newdoc.setDocumentArchive(archive.clone(newdoc.getId(), context));
}
return newdoc;
}
As you can see object.setName() and object.setGuid() are used.
Thanks
-Vincent
On Jan 9, 2010, at 1:25 PM, Pascal Voitot wrote:
I think it's safe to make this change, since the behavior was not
documented, and at least in the official code it wasn't used. does it mean all scripts using the older
functions will need to be updated?
There's only one gotcha right now with what I have on my machine (not committed) and
I'm still hesitating. Internally I've modified the field containing the objects
from
private Map<String, Vector<BaseObject>> objects
to
private Map<DocumentReference, List<BaseObject>> objects
This means that the old (deprecated APIs) have to wrap the internal map. For example when
XWikiDocument.getxWikiObjects() is called it returns a new Map, copying the internal map
to a map of type Map<String, Vector<BaseObject>>. The problem is that if you
have code like the following it'll now fail:
getxWikiObjects().put(something)
Then calling getxWikiObjects() again will not contain the "something" object.
IMO it's a bad usage of the API. Instead if you wish to add something you should call
addObject (now addXObject) for example. However it was allowed and will break old code
which would need to be modified to work.
WDYT? I don't see any solution to preserve the old behavior and at the same time move
to Map<DocumentReference, List<BaseObject>> objects However,
I'd like it to work the same way with the new API, so the new
getXObjects should return a Collections.unmodifiableMap(this.objects)
instead of this.objects, and the read-only result well specified in the
javadoc.
> Thanks
> -Vincent
>
>> Pascal
>>
>> On Sat, Jan 9, 2010 at 12:43 PM, Vincent Massol<vincent(a)massol.net>
wrote:
>>
>>> Hi devs,
>>>
>>> As I mentioned already I'm modifying all APIs in XWikiDocument to use
>>> References (I'm adding new APIs and deprecating old ones).
>>>
>>> While doing this I'm also fixing names for new APIs. So far I'm
modifying 3
>>> things:
>>> - replace Vector by List
>>> - replace Object by XObject in API. For example: getxWikiObjects() -->
>>> getXObjects(), getObjects(String classname) -->
>>> getXObjects(DocumentReference classnameReference)
>>> - replace Class by XClass in API. For example: getxWikiClasses -->
>>> getXClasses()
>>>
>>> Note1: I wanted to use getObject and getClass but getClass is reserved
>>> already.
>>> Note2: in the new model we won't have this problem since we'll
>>> intelligently use another name for object definitions, something like
>>> ObjectDefinition :). We could also change Object but it's less
problematic
>>> and it's probably ok to keep it.
>>>
>>> Here's my +1
>>>
>>> Thanks
>>> -Vincent