On Jan 21, 2010, at 10:34 AM, Anca Luca wrote:
> Hi devs,
>
> On 01/19/2010 03:01 PM, Anca Luca wrote:
>> Hi devs,
>>
>> here's a resume of the approach, as it has been voted so far:
>> 1/ add OBJECT and PROPERTY Entity Types
>>
>> 3 +1, 1 -1: Vincent can you lift your veto from this one, if approach suits
>> you?
>>
>> 2/ using a serialization of the form
>> wiki:Space.Page^className[objectnumber]#property
>> 2 +1 (or 1 +1, 1 +0.5 if we take into account separators votes)
>
> Actually # is causing problems in velocity too, because it's the macro
> invocation char. For example, this
>
> {{velocity}}
> #macro(property)
> this is a test macro
> #end
>
> #set($var1 = "wiki:Space.Page^object#property")
>
> $var1
> {{/velocity}}
>
> displays:
>
> wiki:Space.Page^objectthis is a test macro
>
> Of course, 6th line can be changed to
> #set($var1 = "wiki:Space.Page^object\#property")
> and it will work as expected but the I'd really prefer to avoid escaping,
> since
> it's known to be problematic.
I'm not sure it's a problem. I can't find many examples where we would use
object references in velocity scripts and when we do there's a solution (the
escape as you mentioned).
> Also, Sergiu suggested at some point using the &s, I prefer to avoid that too
> for as long as possible since it can cause problems with URLs.
I don't think it would since the character would be URL-encoded.
> Some proposals would be ^ for object names and pipe or semicolon for
> properties:
Pipe is hard on some keyboards but it shouldn' t be a showstopper.
> wiki:Space.Page^objectName|prop
> wiki:Space.Page^objectName;prop
These separators don't feel natural to me. I think I still prefer the hash.
> or, for property separator, we could also think of ! ~ > or ^ again.
>
> In terms of escaping, it means that every time the property separator
> actually
> appears in the property name, it has to be escaped and every time the object
> separator appears in the object name itself, it has to be escaped.
Yep.
> Knowing this, I'd prefer to keep the ^ as the objectname separator since it's
> quite an unusual char and chances for it to appear in an object name (which
> we
> could think of as "as complex as a document name") are small. For property
> names
> though, I really wouldn't expect any non alphadigit character (other than _)
> to
> ever appear.
Property names could have any character in the future.
Thanks
-Vincent
>
> Thanks,
> Anca
>
>
>> a) implementing with indexed references ('multivalued'):
>> 1 +0.5 , 1 +0,
>> b) implementing with object names computed as className[number]
>> 1 +0.5, 1 +1, 1 -1: Vincent, Sergiu, could you reach some sort of an
>> agreement
>> on this?
>>
>> 3/ how to interpret wiki:Space.Page^className
>> (wiki:Space.Page^className#property)
>>
>> i) consider invalid
>> 1 -0, 1 +1
>> we can consider always valid with the meaning described at
>> http://n2.nabble.com/proposal-discussion-Object-properties-references-tp4348315p4414596.html
>> and the approach voted (iii so far, it seems)
>>
>> ii) as a list of all objects
>> not consistent with references model so far
>>
>> iii) first object
>> 1 +0, 1 +0.75, 1 +1
>>
>> iv) object with index 0
>> 1 +0
>>
>> Unless there are -1s, I would like to start implementing:
>> 1/, 2/, a), iii)
>>
>> Thanks,
>> Anca
>>
>>
>> On 01/18/2010 04: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
