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

On Dec 17, 2009, at 2:14 PM, Thomas Mortagne wrote: Yes I agree it should be the same name but I don't like Persistable actually (for me Persistable is a quality and doesn't represent an entity). I'd prefer Resource over Persistable if I had to choose I think but there might be better names too.

Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 12/17/2009 01:54 PM, Vincent Massol wrote: "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?

>> 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?

We'd have: Entity EntityReference EntityType EntityReferenceFactory, EntityReferenceSerializer I think I prefer it slighty more than Resource. What do others think?

Hi, We'd have: For me "Entity" sounds little bit too generic. I'd prefer "Resource" instead. A "Resource" implies I can use it for something (view, edit, consume etc etc) but "Entity" doesn't give me that feeling (makes me feel like it's something alive!). Anyway, I'm ok with "Entity" if everybody agrees :)

On Dec 17, 2009, at 3:08 PM, Fabio Mancinelli 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.

On Dec 17, 2009, at 3:08 PM, Fabio Mancinelli 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 _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 12/17/2009 09:31 PM, Caleb James DeLisle wrote: Well, these words have a well defined meaning, so as long as they are used in the right context to name the right thing, it should be OK. Do you have any specific examples of places where these terms are used in a confusing way? Except the old xwiki-core core, which we all know is not the best example of Clean Code...

ObjectReference is problematic, since there's the XWiki Object thing, and we would either have to rename the Object entity to something else, or have a strange name for its (java) class (assuming that it's not semantically correct to really use the ObjectReference as both the class for XObjects and as the base class in the Reference hierarchy).

If you look in semantic web definitions, the difference between an entity and a resource is really hard to tell:) Entity seems to be the most generic word to describe something that exists or has existed. On wikipedia, i found this definition: A *resource* is any physical or virtual entity of limited availability, or anything used to help one earn a living.[*citation needed<http://en.wikipedia.org/wiki/Wikipedia:Citation_needed> *] In most cases, commercial or even ethic factors require resource allocation<http://en.wikipedia.org/wiki/Resource_allocation> through resource management<http://en.wikipedia.org/wiki/Resource_management>nt>.

But I don't really like entity because nowadays, this is really associated to a "persisted" entity and no more to a thing of any type...

Pascal On Thu, Dec 17, 2009 at 9:31 PM, Caleb James DeLisle< calebdelisle(a)lavabit.com&gt; wrote: > 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.