Hi Thomas,
On 01/19/2010 12:29 PM, Thomas Mortagne wrote:
> Did not seen there was two threads, reproducing my comments here:
>
> On Mon, Jan 18, 2010 at 15:54, Anca Luca<ancapaula.l...@xwiki.com> 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.
>
> +1
>
>>
>> 2/ using a serialization of the form
>> wiki:Space.Page^className[objectnumber]#property and
>
> +1 for className[objectnumber] syntax
> +0.5 for theses separator, at least i don't see any specific issue
> that theses separators could cause, i think i would have done
> wiki:Space.Page#className[objectnumber]^property because ^ "sounds"
> nicer to me (but i don't have more detailed argument ;))
>
>>
>> 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
>
> I think that's the safest for now until we think more about the model
> et what we want for use case like that. I doubt it's really needed
> yet.
>
>>
>> ii) all objects of class className in the document
>>
>
> That would be a major change in the apis if we make EntityReference
> able to point to several entities. I think i would prefer
> EntityReference mean only one reference but not 100% sure, in any case
> this need more thinking so again +1 of i)
>
>> iii) first object of that class in the document (as
>> XWikiDocument#getObject(className) does)
>>
>
> At least this follow the current general behavior in BaseObject/Object API so
> a user would not be too lost.
>
>> 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).
>>
>
> 0 could point to nothing i think, "first object" make more sense if we
> want it to point to one entity.
but anything could potentially point to nothing, the class could not exist, or
the object or the property name (or a document could not exist), it's more
about
the semantic that we associate with such a reference. The 0 value came rather
from the potential generic approach that an indexed reference which would have
no specified index could be considered as having the index 0.
However, I think it should be the 'first' object, since it is a much more used
reference, and also it's the way the API works (if you ask a prop to be
displayed for a doc, for example, the first object of that class will be used),
so users are accustomed to it.
Thanks,
Anca
>
>> 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
>>> devs@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>> _______________________________________________
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
