21 Jan
2010
21 Jan
'10
10:34 a.m.
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.
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.
Some proposals would be ^ for object names and pipe or semicolon for properties:
wiki:Space.Page^objectName|prop
wiki:Space.Page^objectName;prop
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.
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.
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-tp434…
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs