On 01/18/2010 06:45 PM, Vincent Massol wrote:
>
> 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.
No problem, just wondering if we want it like that or no.
>
> If you have "whatever" and the type is OBJECT then the object name is
> "whatever". Same for Property or any other type.
But you still need to resolve all parents, right? because we don't have
relative
refs, do we?
>
> 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.
yes, that's how I built it.
Thanks,
Anca
>
> 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
