On 01/13/2010 01:42 PM, Anca Luca wrote:
Hi devs,
Short story: 1/ add the CLASS, OBJECT, PROPERTY EntityTypes in the model
+1
2/ serialization for referencing a property of an object a) wiki:Space.Page^className[objectNumber]#property b) wiki:Space.Page^className#objectNumber$property +0.75 for b)
Long story:
1/ I would need to extend the EntityReference to be able to target a property in an object in a document. For this, I will need to add
/** * Represents a Class Entity */ CLASS,
/** * Represents an Object Entity. */ OBJECT,
/** * Represents a Property Entity */ PROPERTY,
+1, but as Vincent said, we must revisit these names. We've agreed for a long time that Class is not a good name. This should be a distinct vote. One question: do you see CLASS as the list of objects of that type in a document, or as the singleton class inside its owner document? If it's the former, then there should also be a property definition. If its the latter, then it's wrongly named.
in the EntityType. Although I would prefer an extensible framework that would allow to extend the possible entity types without changing an enum in the platform (for any API user to be able to define its own references), I think this is fairly extensible (these are key concepts in the xwiki model and I don't think they would be changed that soon, and their interpretation is flexible, they could be combined with any parent to generate either references to class definitions or instances). here's my +1 for this.
I think that an enum is good for the moment. The model won't change easily.
2/ I would also need a 'standard' string serialization for these. Now, there's also the option to do it in my own module (annotations) because only I need it ftm, but I prefer to have a platform wide approach. Opinions? There are 2 choices, with a potentially different combination of separators:
a/ wiki:Space.Page^className[objectNumber]#property
pros: it's a suggestive way to access objects by number ([] is the standard syntax for array indexed access and the objects are accessed by index), [] is supported by JCR so maybe we should support it too cons: [] is somewhat inconsistent with all other separators which are just one separator, to the left (right) of the entity, harder to implement the [] separators on the current framework
b/ wiki:Space.Page^className#objectNumber$property
pros: inline with the separator usage we already have (and easier to implement for this reason), could be easier refactored to contain an object name instead of the number cons: $ separator can collide with velocity syntax (can potentially cause trouble when used in velocity -- an alternative could be the pipe |), could be harder to drop the object number part of the reference to refer a property in a class (if wanted, in the future)
I have no other argument between a) and b) but the implementation speed one, so I'd go for a b)-like approach, in the spirit of the current separators.
What does wiki:Space.Page^className refer to? IMO, if this refers to the class itself, it's wrong. Only XWiki.XWikiUsers^XWiki.XWikiUsers is a valid reference to the XWikiUsers class, while XWiki.Admin^XWiki.XWikiUsers#0 should be used for referring the Admin user. This means that XWiki.Admin^XWiki.XWikiUsers is not a valid reference, although the hierarchical nature of the references would suggest it is. An object reference is not a descendant of a class reference. Given that a class exists only in one document, and (at least for the moment) a document can have at most one class, we could have a different, simpler reference to the class, as in: wiki:Space.Document& wiki:Space.Document&property wiki:Space.Document&property#metaProperty Then, wiki:Space.Document^ would refer to the list of all objects on that page, wiki:Space.Document^className would refer to the list of objects of that type, wiki:Space.Document^className[number], wiki:Space.Document^className[number]#property And the numberless reference is also useful, but that's not quite the same as a full property reference. This means that a lot more reference types are needed. Another important question is where would a link to one of these references point to? -- Sergiu Dumitriu http://purl.org/net/sergiu/