19 Jan
2010
19 Jan
'10
12:50 p.m.
Hi Thomas,
On 01/19/2010 12:29 PM, Thomas Mortagne wrote:
Did not seen there was two threads, reproducing my
comments here:
On Mon, Jan 18, 2010 at 15:54, Anca Luca<ancapaula.luca(a)xwiki.com> wrote:
but anything could potentially point to nothing, the class could not exist, or
the object or the property name (or a document could not exist), it's more about
the semantic that we associate with such a reference. The 0 value came rather
from the potential generic approach that an indexed reference which would have
no specified index could be considered as having the index 0.
However, I think it should be the 'first' object, since it is a much more used
reference, and also it's the way the API works (if you ask a prop to be
displayed for a doc, for example, the first object of that class will be used),
so users are accustomed to it.
Thanks,
Anca
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.
+1
2/ using a serialization of the form
wiki:Space.Page^className[objectnumber]#property and
+1 for className[objectnumber] syntax
+0.5 for theses separator, at least i don't see any specific issue
that theses separators could cause, i think i would have done
wiki:Space.Page#className[objectnumber]^property because ^ "sounds"
nicer to me (but i don't have more detailed argument ;))
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
I think that's the safest for now until we think more about the model
et what we want for use case like that. I doubt it's really needed
yet.
ii) all objects of class className in the document
That would be a major change in the apis if we make EntityReference
able to point to several entities. I think i would prefer
EntityReference mean only one reference but not 100% sure, in any case
this need more thinking so again +1 of i)
iii) first object of that class in the document
(as
XWikiDocument#getObject(className) does)
At least this follow the current general behavior in BaseObject/Object API so
a user would not be too lost.
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).
0 could point to nothing i think, "first object" make more sense if we
want it to point to one entity. 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
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