On Jan 19, 2010, at 4:36 PM, Anca Luca wrote:
> Hi Vincent,
>
> On 01/19/2010 05:11 PM, Vincent Massol wrote:
>> After discussing with Thomas we've reached the following conclusion:
>>
>> * We need to decide if we agree that in the future we want Objects to have a
>> free name (ie any name - when an object is added to a document a computed
>> name could be proposed but the user would be able to choose any name he
>> wants). Our POV is that all Entities in XWiki should have a free name.
>>
>> * If this is agreed then the best solution for now it to consider
>> "classname[number]" as an object name in EntityReference and to have
>> temporary getters in ObjectReference to get the classname and the number
>> (names for the getters to be decided: getIndex, getNumber, getPosition,
>> etc). Of course getName() would perform the serialization. These 2 getters
>> would be temporary and deprecated later on when the model accepts free form
>> object names.
>
> Yes, it's the same question as I was asking, but put otherwise, in a more
> future
> envisaging manner (I think we discussed about it like this at least 2 times
> on
> the development chat).
>
>>
>> This means that if we agree all Entities have a free name then there's no
>> need to have "multivalue"/"indexed" reference names.
>
> However, if we implement it with a multivalued / indexed ref name now, with
> "temporary getters in ObjectReference to get the classname and the number"
> and
> then, when we decide if we agree on having free names we just switch that to
> a
> regular, non-indexed reference, what's the difference?
The difference is that if we want to support Entities without free names then
the correct solution is different. For example a good solution in this case is
to make EntityReference generic re the name (instead of String) and use
xwiki-properties to convert from <T> to String in the generic serializer (or to
any other serialization output).
Thanks
-Vincent
>
> Otherwise put, does the implementation at this point actually depend on this
> decision?
>
> Thanks,
> Anca
>
>>
>> Thanks
>> -Vincent
>>
>> On Jan 18, 2010, at 3: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
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
