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

On Jan 19, 2010, at 4:29 PM, Anca Luca wrote: I'm not sure yet about the names. They may need to be refactored later on. Here's what I propose: * OBJECT * OBJECT_PROPERTY (rather than PROPERTY which looks too ambiguous since we have at least 3 notions of properties)

Thanks -Vincent > WDYT? > >> >>> 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? >> >> I'd like to see Thomas' opinion too. I couldn't find it in his replies. >> >>> 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) >> >> I'm fine with 1/, 2/, A), iii) except for 1/ for which we need to agree on names before you can commit it. >> >> Thanks >> -Vincent >> >>> >>> 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