17 Dec
2009
17 Dec
'09
9:31 p.m.
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Dec 17, 2009, at 1:48 PM, Vincent Massol
wrote:
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
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" 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