On Dec 17, 2009, at 2:47 PM, Sergiu Dumitriu wrote:
On 12/17/2009 01:54 PM, Vincent Massol wrote:
On Dec 17, 2009, at 1:48 PM, Vincent Massol wrote:
Hi devs,
We need to decide if we want to keep the current: ResourceName, DocumentName, SpaceName, WikiName, AttachmentName
or instead use a variation.
There are 2 things to decide: - The prefix for the base object (Resource, Item, Model, etc) - The suffix (Name, Path, Reference, etc)
Proposal =======
I'd like to propose ModelReference for the base object and then DocumentReference, SpaceReference, WikiReference, AttachmentReference.
I'm not sure about ModelReference. We also need to think about the Type, which would be ModelType. Model isn't such a good name, since a Model doesn't represent an "object".
So either we keep Resource which isn't too bad (even though I was feeling it's a bit too generic since we could the notion of Resource in the REST API too and in other APIs) or find another better name (I couldn't find one). Item or Node would be the JCR way of naming it.
Thanks -Vincent
"Reference" is the best name. "Name" is not that good, since it suggests only a name, while in reality it will have other properties, like language and version,
"Model" is too generic. Resource sounds better. How about Entity?
We'd have: Entity EntityReference EntityType EntityReferenceFactory, EntityReferenceSerializer I think I prefer it slighty more than Resource. What do others think? Thanks -Vincent
Note: This is different from Identity which is unique (a UUID). 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.
Path is too physical to me. In JCR it's called getPath() but it returns a string with a path, for ex "/wiki/space1/space2/document". This is not our case. IMO our Reference would transform into a path when serialized only.
Name isn't too bad, it would be my second choice. But it doesn't show the fact that it's a ... reference... ;)
WDYT?