On Jan 18, 2010, at 5:32 PM, Anca Luca wrote:
> On 01/18/2010 05:54 PM, Anca Luca wrote:
>> Hi Vincent,
>>
>> On 01/18/2010 05:41 PM, Vincent Massol wrote:
>>>
>>> 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.
>>>
>>> We need to define the names we're going to use first so I'm putting a -1 to
>>> block till we define them.
>>>
>>>> 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.
>>>
>>> -1 for b) since
>>> - we would need to recode resolvers, serializers and a data object to hold
>>> the data, basically redoing everything I've done for References.
>>> - it would make a not nice API
>>>
>>> +0 for a)
>>>
>>>> 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
>>>
>>> -0
>>>
>>> Right now all our resolvers never throw an exception. I'd like to keep them
>>> like this as much as possible.
>
> Actually on second thought, if we want always parsable references, we need to
> also find out how to resolve a string with no ^ and/or # separators as
> Object,
> respective Property.
I don't see the problem.
If you have "whatever" and the type is OBJECT then the object name is
"whatever". Same for Property or any other type.
If you have "wiki:Space.Page#prop" and the type is OBJECT then the object name
is "wiki:Space.Page#prop".
This is similar than for wiki, space, page, attachment, etc.
Thanks
-Vincent
>
> A 'current' resolver could resolve "FooBar" as:
> - currentDocRef^FooBar when of type object (the object (as per ii, iii or iv)
> of
> type FooBar in the current document, as resolved by the
> CurrentStringDocumentReferenceResolver resolver)
> - currentDocRef^currentDocRef#FooBar when of type property (the property
> FooBar
> in the current document (as resolved by the
> CurrentStringDocumentReferenceResolver resolver), of the object (as per ii,
> iii
> or iv) of the class defined by the document reference)
>
> In similar manner, a 'default' resolver could resolve "FooBar" as:
> - defaultDocRef^FooBar when of type object
> - defaultDocRef^defaultClass#FooBar when of type property (where defaultClass
> is
> either defaultDocRef (see above) or a different class, which we agree to be
> the
> default)
>
> Also, a string like wiki:Space.Page#prop parsed as object would have to be
> interpreted as 'FooBar' above, and parsed as property, would have the
> property
> specified as "prop" of the object obtained by parsing 'wiki:Space.Page" as
> 'FooBar' above.
>
> WDYT?
>
> (I hope I didn't mess it up, I know it's complicated, but it has to make
> sense.)
>
>>
>> I think it's not that bad that they'd throw, IMO it's a particular case the
>> one
>> we have now where all serializations make sense and can be interpreted as
>> valid
>> (in other words, having a factory that requires a format for the strings it
>> parses is only normal).
>>
>>>
>>>> ii) all objects of class className in the document
>>>
>>> I don't think it's valid. What would wiki:Space.Page^className#property
>>> mean?
>>
>> could mean, by extension, the list of all values for property for all
>> objects of
>> class className in the document.
>> Which means we'd need to define OBJECT_LIST and PROPERTY_VALUE_LIST or
>> something
>> as EntityTypes.
>
> Actually, if we add new types for this, then we still have to find a way to
> interpret wiki:Space.Page^className as Object or Property (since everything
> has
> to make sense as everything), which brigs us in a bit of a loop.
>
>>
>>>
>>>> iii) first object of that class in the document (as
>>>> XWikiDocument#getObject(className) does)
>
> If considering as invalid is harder than parsing, I go for this one:
>
> +1
>
> Thanks,
> Anca
>
>>>
>>>> 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).
>>>
>>> What is the reason? So that object names don't move when objects are
>>> added/removed?
>>
>> yes, because they are identified by their index.
>>
>>>
>>> I don't know enough but +0 for iii) or iv).
>>>
>>> Thanks
>>> -Vincent
>>>
>>>> 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
