18 Jan
2010
18 Jan
'10
5:45 p.m.
On Jan 18, 2010, at 5:32 PM, Anca Luca wrote:
On 01/18/2010 05:54 PM, Anca Luca wrote:
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
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.
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).
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.
ii) all objects of class className in the
document
I don't think it's valid. What would wiki:Space.Page^className#property mean?
>
>> 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