Hi, Big +1 for getUUID() and storing UUID as byte[] and returning java.util.UUID Storage as byte[] will improve db load times. Whatever you like for a name is fine for me but I would caution against over generic words such as "Model", "Context", "Factory", and "Manager" because when I first began reading the source, I often found these terms unhelpful. Perhaps ObjectReference instead of ModelReference? This would make sense if and when Document, Space, Attachment, and Wiki extend Object. Caleb Vincent Massol wrote:
On Dec 17, 2009, at 3:08 PM, Fabio Mancinelli wrote:
On Dec 17, 2009, at 1:48 PM, Vincent Massol wrote:
Proposal =======
I'd like to propose ModelReference for the base object and then DocumentReference, SpaceReference, WikiReference, AttachmentReference. Note: This is different from Identity which is unique (a UUID). References do not point to unique objects.
I am not sure of having understood the note. In particular what you mean when you say "references do not point to unique objects"
The way I view it is that an object (or Entity or Resource) will have 2 methods: - getReference() (corresponds to Node.getPath() in JCR I believe) - getUUID()
In other words, it's possible to have several References pointing to the same object (or Entity or Resource). This is very useful for implementing renames for example.
In addition, FTM I'm not sure if a Reference should include the version
I need for think a bit more about this since I'm not 100% sure. If you have ideas let me know.
Thanks -Vincent
Reference makes sense to me since it means what it means... :) For example the API: Document getDocument(DocumentReference) is pretty clear IMO.
I would say ResourceReference for the base object and DocumentReference, SpaceReference, WikiReference, AttachmentReference for the specific resource type references.
-Fabio
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs