[xwiki-devs] [Proposal] Resource vs Item vs ItemResource vs Model & Name vs Path vs Reference
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. 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? Thanks -Vincent
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
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?
Thanks -Vincent
On Thu, Dec 17, 2009 at 13:54, Vincent Massol <[email protected]> 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.
Another idea: PersistableReference since all theses are implementing Persistable interface in your current model proposal, seems logical to me or it mean Persistable is not the right name for this interface.
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?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Dec 17, 2009, at 2:14 PM, Thomas Mortagne wrote:
On Thu, Dec 17, 2009 at 13:54, Vincent Massol <[email protected]> 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.
Another idea: PersistableReference since all theses are implementing Persistable interface in your current model proposal, seems logical to me or it mean Persistable is not the right name for this interface.
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
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?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Dec 17, 2009 at 14:18, Vincent Massol <[email protected]> wrote:
On Dec 17, 2009, at 2:14 PM, Thomas Mortagne wrote:
On Thu, Dec 17, 2009 at 13:54, Vincent Massol <[email protected]> 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.
Another idea: PersistableReference since all theses are implementing Persistable interface in your current model proposal, seems logical to me or it mean Persistable is not the right name for this interface.
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.
+1 for Resource and ResourceReference then
Thanks -Vincent
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?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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?
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?
-- Sergiu Dumitriu http://purl.org/net/sergiu/
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?
On Thu, Dec 17, 2009 at 15:38, Vincent Massol <[email protected]> wrote:
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?
Yes Entity seems the right name.
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?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Dec 17, 2009, at 3:38 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?
We'd have:
Entity EntityReference EntityType EntityReferenceFactory, EntityReferenceSerializer
I think I prefer it slighty more than Resource. What do others think?
Yes, Entity sounds better. -Fabio
Hi, We'd have:
Entity EntityReference EntityType EntityReferenceFactory, EntityReferenceSerializer
I think I prefer it slighty more than Resource. What do others think?
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 :) Thanks. - Asiri
On Dec 17, 2009, at 5:52 PM, Asiri Rathnayake wrote:
Hi,
We'd have:
Entity EntityReference EntityType EntityReferenceFactory, EntityReferenceSerializer
I think I prefer it slighty more than Resource. What do others think?
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 :)
Well Entity is pretty common in modeling (see http://bit.ly/5r2Liw) Also it's used in Entity Bean (Java EE) and is defined as: "An entity bean represents a business object in a persistent storage mechanism. Some examples of business objects are customers, orders, and products" Thanks -Vincent
Hi Vincent, Well Entity is pretty common in modeling (see http://bit.ly/5r2Liw)
Also it's used in Entity Bean (Java EE) and is defined as: "An entity bean represents a business object in a persistent storage mechanism. Some examples of business objects are customers, orders, and products"
Exactly my point, you can call anything an "Entity". Normally we'd model real world entities (cutomer, order, part, product, etc etc.) in an ER diagram. But in our use case we have Space, Page, Attachment, Wiki etc. etc. for which "resource" seems to be little bit more descriptive. But may be it's just the way I have used to percieve things. So, let's go ahead with "Entity". Thanks. - Asiri
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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"
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
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
On Dec 17, 2009, at 3:36 PM, 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.
If I understand well you are suggesting that every object-or-entity-or-resource have a UUID and can be addressed by using a reference that contains declarative information. So, for example a page P will have a UUID X and "Main.WebHome" could be a reference to the page P. A rename is just a change of components of the reference so that now the new reference "Foo.Bar" will still point to page P whose UUID is X but appears to be in the space "Foo" and having the "Bar" name. This could also allow for "symbolic linking"... For example the page P with UUID X might be pointed by a set of references "Main.WebHome", "Foo.Bar", "X.Y" making it appear in different spaces under different names. In this case the objects-or-entities-or-resources exist in a flat space and the structural organization (i.e., a page is in a space that is in another space in a given wiki, etc.) is subsumed by the references like what happens in RDF graphs.
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.
Maybe not... Versions could be first-class bject-or-entity-or-resource that can be referenced (this is what happens in the REST API for example). -Fabio
On Dec 17, 2009, at 4:05 PM, Fabio Mancinelli wrote:
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.
Maybe not... Versions could be first-class bject-or-entity-or-resource that can be referenced (this is what happens in the REST API for example).
Ooops, sorry. This means putting the version in the reference... So what I really wanted to write was "Maybe yes" :) -Fabio
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
On 12/17/2009 09:31 PM, Caleb James DeLisle 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.
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...
Perhaps ObjectReference instead of ModelReference? This would make sense if and when Document, Space, Attachment, and Wiki extend Object.
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).
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.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu wrote: > On 12/17/2009 09:31 PM, Caleb James DeLisle 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. > > 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... Yes, the old core is exactly what I was thinking of. My only concern is that new contributors can understand the source even if they are not experienced programmers. Caleb > >> Perhaps ObjectReference instead of ModelReference? This would make sense >> if and when Document, Space, Attachment, and Wiki extend Object. > > 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). > >> 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. > >
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>. 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 < [email protected]> 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.
-Fabio
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 12/17/2009 10:30 PM, Pascal Voitot wrote:
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>.
I also tend to associate Resource with something that can be measured and priced, like water or wood.
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...
How come? Why do you associate the "persisted" feature? And isn't it good, since the model will be persisted in the storage?
Pascal
On Thu, Dec 17, 2009 at 9:31 PM, Caleb James DeLisle< [email protected]> 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.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Thu, Dec 17, 2009 at 11:07 PM, Sergiu Dumitriu <[email protected]> wrote:
On 12/17/2009 10:30 PM, Pascal Voitot wrote:
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>.
I also tend to associate Resource with something that can be measured and priced, like water or wood.
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...
How come? Why do you associate the "persisted" feature? And isn't it good, since the model will be persisted in the storage?
Tell any java developer:"entity" and he will speak about persistence :)... But you're right, it's not so bad. Anyway, entity always gives me the impression of dealing with "some thing". You know in french we have a word to represent anything: we say "truc"... entity is a bit like that ;)
Pascal
On Thu, Dec 17, 2009 at 9:31 PM, Caleb James DeLisle< [email protected]> 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.
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (7)
-
Asiri Rathnayake -
Caleb James DeLisle -
Fabio Mancinelli -
Pascal Voitot -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol