On 01/20/2010 04:12 PM, Vincent Massol wrote:
>
> On Jan 19, 2010, at 4:29 PM, Anca Luca wrote:
>
>> Hi Vincent,
>>
>> On 01/19/2010 03:12 PM, Vincent Massol wrote:
>>>
>>> On Jan 19, 2010, at 2:01 PM, Anca Luca wrote:
>>>
>>>> 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?
>>>
>>> As I said I'm -1 on this till we agree on the names.
>>
>> The constant names you mean?
>>
>> If so, I propose OBJECT and PROPERTY, as mentioned above, which also seem to
>> be
>> 'inline' with the new model on the sandbox (although there is no property
>> instance there). And when we'll need the other ones, which is not the case
>> now,
>> we can use OBJECT_DEFINITION and OBJECT_DEFINITION_PROPERTY.
>>
>> here's my +1,
>
> 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)
+1
> 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-tp4348315p4414596.html
>>>> 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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
