20 Jan
2010
20 Jan
'10
11:41 a.m.
On Wed, Jan 20, 2010 at 11:32, Vincent Massol <vincent(a)massol.net> wrote:
On Jan 19, 2010, at 5:35 PM, Anca Luca wrote:
+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)
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.
Thanks
-Vincent
--
Thomas Mortagne
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs