On Wed, Jan 20, 2010 at 11:32, Vincent Massol <vincent@massol.net> wrote:

On Jan 19, 2010, at 5:35 PM, Anca Luca wrote:

...

Hi devs,

Short story:

In the new model, does it make sense to support entities that don't have an unique name to be identified in their 'context'? (so-called 'free name', as in free thought).

+1 to force all Entities to have a free form name in the new model

Notes: * Tthat name could be automatically generated when an object is created. We could use the format <classname> for the first one and then <classname>2, ... <classname>N - or even <classname>[N] is we want backward compatibility. * One advantage of always having a name is that there's no problem with removing an object and thus having a different index or having an index with holes. The object is always addressable. * Another advantage is that scripts can be a bit more clean by using a name with a meaning rather than <className>[N]. For example instead of TagClass[1] it could use "CommentTags", ie associate a business meaning with a given object.

+1, not much to add except * i don't see any valid use case to have complex names/ids (composed with several values instead of a simple String) at Entity level so better not implement it (because it would be more complex, slower and potentially buggy)

Thanks -Vincent

...

WDYT?

Long story:

For example, in the current model, an object is an example of entity that does _not_ have a free name: in a document (its context), an object is identified by two values: the name of the class of the object and the 'object number'. An object cannot be differentiated by a single name among all the objects of a document. As opposed to this, a document does have a free name to identify it in the list of documents in a space, namely the page name. The same, an attachment's name is unique among the attachments of a page, etc.

Note that the discussion is about a human-readable and accessible name for an entity, for example, using a GUID or other 'identifier' is not an option, since they are not manipulable by humans (for example to create a reference to such an entity).

Also note that, even if supporting it is the best solution (which covers all cases anyway), we want to make sure it's necessary, since it would involve some refactoring.

Thanks, Anca

P.S. I haven't made my mind yet.

---

devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

On 01/20/2010 01:09 PM, Anca Luca wrote:

Hi Vincent, all

On 01/20/2010 12:32 PM, Vincent Massol wrote:

...

On Jan 19, 2010, at 5:35 PM, Anca Luca wrote:

...

Hi devs,

Short story:

In the new model, does it make sense to support entities that don't have an unique name to be identified in their 'context'? (so-called 'free name', as in free thought).

+1 to force all Entities to have a free form name in the new model

all referencable entities, I would add.

...

Notes: * Tthat name could be automatically generated when an object is created. We could use the format<classname> for the first one and then<classname>2, ...<classname>N - or even<classname>[N] is we want backward compatibility. * One advantage of always having a name is that there's no problem with removing an object and thus having a different index or having an index with holes. The object is always addressable. * Another advantage is that scripts can be a bit more clean by using a name with a meaning rather than<className>[N]. For example instead of TagClass[1] it could use "CommentTags", ie associate a business meaning with a given object.

Indeed for _objects_ there are countless arguments to have names (it's probably gonna cause quite some mess to maintain, but so does the (current) indexing method).

For entities in general (that is, objects and who knows what else), I'm not that 100% sure, but since I don't see a use case now, and we don't want to refactor, and we can always workaround (as we'll do for objects for the moment), let's go,

+1

+1 for enforcing having free names on all referencable entities that is.

Thanks, Anca

...

Thanks -Vincent

...

WDYT?

Long story:

For example, in the current model, an object is an example of entity that does _not_ have a free name: in a document (its context), an object is identified by two values: the name of the class of the object and the 'object number'. An object cannot be differentiated by a single name among all the objects of a document. As opposed to this, a document does have a free name to identify it in the list of documents in a space, namely the page name. The same, an attachment's name is unique among the attachments of a page, etc.

Note that the discussion is about a human-readable and accessible name for an entity, for example, using a GUID or other 'identifier' is not an option, since they are not manipulable by humans (for example to create a reference to such an entity).

Also note that, even if supporting it is the best solution (which covers all cases anyway), we want to make sure it's necessary, since it would involve some refactoring.

Thanks, Anca

P.S. I haven't made my mind yet.

---

devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Sergiu, On 01/20/2010 05:14 PM, Sergiu Dumitriu wrote:

On 01/19/2010 05:35 PM, Anca Luca wrote:

...

Hi devs,

Short story:

In the new model, does it make sense to support entities that don't have an unique name to be identified in their 'context'? (so-called 'free name', as in free thought).

+1

+1 is for enforcing entities to have free names? (i.e. adding names to objects in the future) or for refactoring to support entities that don't have free names? Thanks, Anca

...

WDYT?

Long story:

For example, in the current model, an object is an example of entity that does _not_ have a free name: in a document (its context), an object is identified by two values: the name of the class of the object and the 'object number'. An object cannot be differentiated by a single name among all the objects of a document. As opposed to this, a document does have a free name to identify it in the list of documents in a space, namely the page name. The same, an attachment's name is unique among the attachments of a page, etc.

Note that the discussion is about a human-readable and accessible name for an entity, for example, using a GUID or other 'identifier' is not an option, since they are not manipulable by humans (for example to create a reference to such an entity).

Also note that, even if supporting it is the best solution (which covers all cases anyway), we want to make sure it's necessary, since it would involve some refactoring.

Thanks, Anca

On Jan 20, 2010, at 4:14 PM, Sergiu Dumitriu wrote:

On 01/19/2010 05:35 PM, Anca Luca wrote:

...

Hi devs,

Short story:

In the new model, does it make sense to support entities that don't have an unique name to be identified in their 'context'? (so-called 'free name', as in free thought).

+1

This +1 means you don't agree with Thomas, Anca and me right? If so, could you justify your answer? Thanks -Vincent

...

WDYT?

Long story:

For example, in the current model, an object is an example of entity that does _not_ have a free name: in a document (its context), an object is identified by two values: the name of the class of the object and the 'object number'. An object cannot be differentiated by a single name among all the objects of a document. As opposed to this, a document does have a free name to identify it in the list of documents in a space, namely the page name. The same, an attachment's name is unique among the attachments of a page, etc.

Note that the discussion is about a human-readable and accessible name for an entity, for example, using a GUID or other 'identifier' is not an option, since they are not manipulable by humans (for example to create a reference to such an entity).

Also note that, even if supporting it is the best solution (which covers all cases anyway), we want to make sure it's necessary, since it would involve some refactoring.

Thanks, Anca