Re: [xwiki-devs] [VOTE] [Result] Object properties references (was [proposal][discussion])

Hi devs, here's a resume of the approach, as it has been voted so far: 1/ add OBJECT and PROPERTY Entity Types 3 +1, 1 -1: Vincent can you lift your veto from this one, if approach suits you?

2/ using a serialization of the form wiki:Space.Page^className[objectnumber]#property 2 +1 (or 1 +1, 1 +0.5 if we take into account separators votes) a) implementing with indexed references ('multivalued'): 1 +0.5 , 1 +0, b) implementing with object names computed as className[number] 1 +0.5, 1 +1, 1 -1: Vincent, Sergiu, could you reach some sort of an agreement on this?

3/ how to interpret wiki:Space.Page^className (wiki:Space.Page^className#property) i) consider invalid 1 -0, 1 +1 we can consider always valid with the meaning described at http://n2.nabble.com/proposal-discussion-Object-properties-references-tp434… and the approach voted (iii so far, it seems) ii) as a list of all objects not consistent with references model so far iii) first object 1 +0, 1 +0.75, 1 +1 iv) object with index 0 1 +0 Unless there are -1s, I would like to start implementing: 1/, 2/, a), iii)

Thanks, Anca On 01/18/2010 04:54 PM, Anca Luca wrote: > Hi devs, > > to resume, and try to converge to an implementable version, I propose: > > 1/ adding only OBJECT and PROPERTY EntityTypes for the moment, referring to an > object instance and a property instance in a document (a property ref would have > an object as a parent which would have a document reference as a parent), and > limiting the implementation to references to properties of object instances > (leaving aside type definitions ftm). > > here's my +1 for this. > > 2/ using a serialization of the form > wiki:Space.Page^className[objectnumber]#property and > > a) using indexed ('multivalued') references, adding an additional > IndexedEntityReference class, to which API caller would have to cast. > ObjectReference would be such an IndexedEntityReference and provide object > related helper functions. > > b) className[objectnumber] is used as an 'object name', it would be the name of > the object reference, and it would be the caller of the generic API that would > have to parse& serialize this kind of strings to actually extract classname and > object index. However, this would again be all hidden behind the ObjectReference > API. > > I'm 0.5 and 0.5 between the two, any would suit my purpose. > > An additional question is what would wiki:Space.Page^className (and > wiki:Space.Page^className#property) mean: > i) nothing, we consider it as invalid reference, we'll fix that later, we keep > it simple ftm > > my +1 goes for this > > ii) all objects of class className in the document > > iii) first object of that class in the document (as > XWikiDocument#getObject(className) does) > > iv) a shortcut for wiki:Space.Page^className[0] (which, note, does not > necessarily mean the first object in that document, since indexing of objs in a > document is not recomputed when objects are deleted). > > WDYT? > > Thanks, > Anca > > On 01/13/2010 02: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, >> >> 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. >> >> 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. >> >> WDYT? >> >> Thanks, >> Anca