17 Jan
2010
17 Jan
'10
6:01 p.m.
Hi Sergiu,
On 01/17/2010 03:07 PM, Sergiu Dumitriu wrote:
indeed, but one would want to add their own types for their own structures of
content, or hierarchies et all. It would be possible if reference types were
extensible. One developer that is, that develops an extra module for xwiki (such
as the annotations, for example, or a specific customization).
In my proposal, it wasn't suppose to mean anything, but it could have been
extended to refer the class, indeed. But I agree that it's gonna have to be kept
valid (for your reason below).
Now, if I think about
it, I wonder why do we need these references like this in
the first place? New string serialization, separators definition, components
definitions, etc why not addressing with some rest-style URLs (and we'd have a
unified way for both these refs and the REST module) where components of the
reference are named. In the end, the problem is to address resources, isn't it?
</thinkingoutloud
Thanks,
Anca
On 01/13/2010 01:42 PM, Anca Luca wrote:
I was thinking of class as both, interpreted by the full reference it appears
in, but I don't think that's quite feasible since the reference interpretation
is given by its type and not by its parents (which would be too ambiguous).
In this case, we need to think about how we want to refer to an object (given
that an object doesn't have a name and we cannot use "context" of the
reference).
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,
+1, but as Vincent said, we must revisit these names. We've agreed for a
long time that Class is not a good name. This should be a distinct vote.
One question: do you see CLASS as the list of objects of that type in a
document, or as the singleton class inside its owner document? If it's
the former, then there should also be a property definition. If its the
latter, then it's wrongly named. 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.
I think that an enum is good for the moment. The model won't change easily. 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.
What does wiki:Space.Page^className refer to?
IMO, if this refers to the class itself, it's wrong. Only
XWiki.XWikiUsers^XWiki.XWikiUsers is a valid reference to the XWikiUsers
class, while XWiki.Admin^XWiki.XWikiUsers#0 should be used for referring
the Admin user. This means that XWiki.Admin^XWiki.XWikiUsers is not a
valid reference, although the hierarchical nature of the references
would suggest it is.
An object reference is not a descendant of a class reference.
I'm not yet convinced that we want to enforce the semantic hierarchies of the
xwiki model to references. What you're saying here is that EntityReference1 is
parent of EntityReference2 makes it mandatory for the entity represented by
reference 1 to be a parent of the entity represented by reference 2. I am not
against this, but I was seeing things slightly more loose, as in references are
more some sort of a syntax to address things, not mandatory to have the same
structure as the stuff they're representing.
Given that a class exists only in one document, and (at least for the
moment) a document can have at most one class, we could have a
different, simpler reference to the class, as in:
wiki:Space.Document&
wiki:Space.Document&property
wiki:Space.Document&property#metaProperty
Then, wiki:Space.Document^ would refer to the list of all objects on
that page, wiki:Space.Document^className would refer to the list of
objects of that type, wiki:Space.Document^className[number],
wiki:Space.Document^className[number]#property
And the numberless reference is also useful, but that's not quite the
same as a full property reference.
This means that a lot more reference types are needed.
I don't have a strong opinion pro or against this, fine by me.
Another important question is where would a link to one of these
references point to?
Why would it have to? the link references are only a subset of the references in
general...
<thinkingoutloud