Hi Thomas, On 01/13/2010 09:43 PM, Thomas Mortagne wrote:

On Wed, Jan 13, 2010 at 13:42, Anca Luca<[email protected]> 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?

1/ +1

2/ +1 for single separator like in b/ but not sure about the right separators to choose. Note that there is strong technical reason to choose different separators, could be "wiki:Space.Page#className#objectNumber#property" for example or any other separator.

however, if we use the same separator we lose the possibility to drop the object name, for example to build references to class property definitions (wiki:Space.Page^className#property) or class names to refer properties of documents (for the future typed documents, for example). I'm not sure if we really want this kind of things right now, but it's good to envisage for the future. I still don't have a very strong opinion for one or other of the separators. Thanks, Anca

For document reference there was the backward compatibility aspect but not here. In any case i would prefer not use $ since it would be a pain in velocity I think as you said.

...

Thanks, Anca

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Vincent, On 01/15/2010 03:42 PM, Vincent Massol wrote:

Hi Anca,

On Jan 13, 2010, at 1: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.

+1 in general but this raises the question of choosing how we name these entities in the new model. For example in sandbox I have the following right now: - Object - ObjectDefinition - ObjectDefinitionProperty

...

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.

Well from a technical pov both a/ and b/ require supporting multivalues. This means changing several classes. For exemple we'd need to have both EntityReference and some kind of IndexedEntityReference that would add get/setPosition() methods.

We'd need to rethink quite a few things probably since otherwise we'd need to use a cast to get access to it, which isn't good.

Alternatively we'd need to add get/setPosition() in EntityReference but they wouldn't have much meaning (we'd consider they always return 0 for ex) for non-multivalued references.

as we discussed on the chat (but logging here for posterity), indeed I wasn't necessarily viewing this in terms of multivalues but in terms of entity of type Object holds the value of the object number and is a child of the entity of type Class which has the class of the object as value and whose parent is the entity of type document. (btw, this reminds me the className _is_ actually, in any case, a Document reference because the class is a document. I wonder how smooth parsing would go).

Now in term of serialization I find the [] option (ie option a) more natural for a user and more readable. It's slightly more complex to implement but that shouldn't be our deciding factor IMO.

if we go for multivalued yes, [] is the most natural approach.

Re the separator chars, they look ok to me.

I believe more and more we should stay away from $. Thanks, Anca

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Sergiu, On 01/17/2010 03:07 PM, Sergiu Dumitriu wrote:

On 01/13/2010 01: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,

+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.

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).

...

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.

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).

...

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?

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).

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> 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 Mon, Jan 18, 2010 at 15:41, Anca Luca <[email protected]> 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.

+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 mojor 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 XWikiDocument 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

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.

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)

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? 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

On 01/18/2010 05:54 PM, Anca Luca wrote:

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).

...

...

ii) all objects of class className in the document

I don't think it's valid. What would wiki:Space.Page^className#property mean?

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.

...

...

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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 01/18/2010 06:45 PM, Vincent Massol wrote:

On Jan 18, 2010, at 5:32 PM, Anca Luca wrote:

...

On 01/18/2010 05:54 PM, Anca Luca wrote:

...

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.

I don't see the problem.

No problem, just wondering if we want it like that or no.

If you have "whatever" and the type is OBJECT then the object name is "whatever". Same for Property or any other type.

But you still need to resolve all parents, right? because we don't have relative refs, do we?

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.

yes, that's how I built it. Thanks, Anca

Thanks -Vincent

...

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).

...

...

ii) all objects of class className in the document

I don't think it's valid. What would wiki:Space.Page^className#property mean?

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.

...

...

...

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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 01/18/2010 06:04 PM, Sergiu Dumitriu wrote:

On 01/18/2010 03: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.

+1

...

2/ using a serialization of the form wiki:Space.Page^className[objectnumber]#property and

+1

...

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)

...

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).

+0.75 for iii), the problem being that it is not a "stable" reference. Is that a major problem? IMO not, since all other references are unstable, since a document can be deleted and recreated, too.

I think that would be fine, it's just a matter of semantic, you don't actually have to have it there but only know how to interpret it. In this case we'd need specific API for the ObjectReference to detect this situation (either return a special value for index and know it means "default" or actually address the situation with is**** function). 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.

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<[email protected]> 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.

+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.

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

...

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

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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) 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-tp4348... 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

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Vincent, On 01/19/2010 03:12 PM, Vincent Massol wrote:

On Jan 19, 2010, at 2: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?

As I said I'm -1 on this till we agree on the names.

The constant names you mean? If so, I propose OBJECT and PROPERTY, as mentioned above, which also seem to be 'inline' with the new model on the sandbox (although there is no property instance there). And when we'll need the other ones, which is not the case now, we can use OBJECT_DEFINITION and OBJECT_DEFINITION_PROPERTY. here's my +1, WDYT?

...

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) 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?

I'd like to see Thomas' opinion too. I couldn't find it in his replies.

...

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-tp4348... 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)

I'm fine with 1/, 2/, A), iii) except for 1/ for which we need to agree on names before you can commit it.

Thanks -Vincent

...

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

On 01/20/2010 04:12 PM, Vincent Massol wrote:

On Jan 19, 2010, at 4:29 PM, Anca Luca wrote:

...

Hi Vincent,

On 01/19/2010 03:12 PM, Vincent Massol wrote:

...

On Jan 19, 2010, at 2: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?

As I said I'm -1 on this till we agree on the names.

The constant names you mean?

If so, I propose OBJECT and PROPERTY, as mentioned above, which also seem to be 'inline' with the new model on the sandbox (although there is no property instance there). And when we'll need the other ones, which is not the case now, we can use OBJECT_DEFINITION and OBJECT_DEFINITION_PROPERTY.

here's my +1,

I'm not sure yet about the names. They may need to be refactored later on.

Here's what I propose:

* OBJECT * OBJECT_PROPERTY (rather than PROPERTY which looks too ambiguous since we have at least 3 notions of properties)

+1

Thanks -Vincent

...

WDYT?

...

...

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) 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?

I'd like to see Thomas' opinion too. I couldn't find it in his replies.

...

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-tp4348... 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)

I'm fine with 1/, 2/, A), iii) except for 1/ for which we need to agree on names before you can commit it.

Thanks -Vincent

...

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

-- Sergiu Dumitriu http://purl.org/net/sergiu/

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-tp4348... 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

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 01/21/2010 11: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.

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

I like how this looks, my vote goes here +1 for ^ and ; Thanks, Anca

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-tp4348... 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

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Vincent, On 01/21/2010 11:52 AM, Vincent Massol wrote:

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).

I disagree here. I think that's why we're bothering to create these refs, to be used in scripts (in their serialized form). I would use them in scripts in annotations. Also, the devs will have to escape that hash _every single time_ since macros can be defined by other sources than themselves and available in the context they're running their script in (e.g. macros.vm) and collide with the property name and cause unexpected results. I prefer to avoid this case if possible, because devs will forget to do that, otherwise put, less bugs than more, if i have the choice. From my memories of scripting in XWiki, escaping in velocity can be an issue. Think about having more sophisticated constructions with strings that contain calls of object functions with strings as parameters, normally that works but when it comes to escaping there can be pbs. Or this might have been a problem only in syntax 1.0 since there were 4 syntaxes on top of eachother, I don't know, but I prefer to avoid it, if possible.

...

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.

it _can_ be url encoded, but nothing guarantees that people wouldn't forget to do it. otherwise put, less bugs than more if I have the choice.

...

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.

They can now too, I think, just the same way the object name can have a ^. My expectation is only a general feeling about how I know programmers name their field names. It's a question of small probability, not impossibility. Even if we expose types creation to 'regular non-devs' users (with a wizard or something), I still think property names would stay a lot simpler than document names, for example (I don't see anyone adding a full sentence as a property name, with punctuation, and whatever chars, while I see them naming a document with a sentence). Thanks, Anca

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-tp4348... 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

Hi Flavius, On 01/21/2010 02:53 PM, Flavius Olaru wrote:

Hi all,

I don't know, maybe this might be a stupid question/proposal, but why not replicate from usage of wiki:Space.Page to object and their properties. The Page is like a wiki for objects and properties are like pages for spaces.... Is it hard to implement this?

no, there shouldn't be any problem in implementing this.

I think the more notations... the harder is to see the code and understand it.

depending on where you're looking from, same separator for different entities can be a bit confusing too (since when you see . you think about space page separator only to later realize, ah there's another dot which is actually the separator, etc. Also think that these serialized forms could be relative, e.g. not contain the document part but only the object.property part. While the code won't have any issue with it, the user reading it might...) Also the model of interpreting objects in pages as spaces in a wiki and properties in obj as pages in a space, and using the same separator could be a bit confusing since it's not really the same thing (though the parallel is somewhat legitimate) and we're just mixing them up in the user's head. It depends on how you look at things.

wiki:Space.Page:object.property

. is indeed a very good (read "intuitive") separator between objects and properties. However, like this, the object would have to escape its :s. there would be a tiny issue with one of the currently possible implementations of the name (which is the classname[objectnumber], since if one wants class name absolute it would have to use a : which would need to be escaped and the ref would be less visible), but that shouldn't stop the approach for the new model. All in all, I think it's a good idea, as I said I like the dot intuitive separator. +0 Anca

Thanks, Flavius

On Thu, Jan 21, 2010 at 12:14 PM, Anca Luca<[email protected]> wrote:

...

Hi Vincent,

On 01/21/2010 11:52 AM, Vincent Massol wrote:

...

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).

I disagree here. I think that's why we're bothering to create these refs, to be used in scripts (in their serialized form). I would use them in scripts in annotations. Also, the devs will have to escape that hash _every single time_ since macros can be defined by other sources than themselves and available in the context they're running their script in (e.g. macros.vm) and collide with the property name and cause unexpected results. I prefer to avoid this case if possible, because devs will forget to do that, otherwise put, less bugs than more, if i have the choice. From my memories of scripting in XWiki, escaping in velocity can be an issue. Think about having more sophisticated constructions with strings that contain calls of object functions with strings as parameters, normally that works but when it comes to escaping there can be pbs. Or this might have been a problem only in syntax 1.0 since there were 4 syntaxes on top of eachother, I don't know, but I prefer to avoid it, if possible.

...

...

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.

it _can_ be url encoded, but nothing guarantees that people wouldn't forget to do it. otherwise put, less bugs than more if I have the choice.

...

...

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.

They can now too, I think, just the same way the object name can have a ^. My expectation is only a general feeling about how I know programmers name their field names. It's a question of small probability, not impossibility.

Even if we expose types creation to 'regular non-devs' users (with a wizard or something), I still think property names would stay a lot simpler than document names, for example (I don't see anyone adding a full sentence as a property name, with punctuation, and whatever chars, while I see them naming a document with a sentence).

Thanks, Anca

...

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-tp4348... 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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

After discussing with Thomas we've reached the following conclusion: * We need to decide if we agree that in the future we want Objects to have a free name (ie any name - when an object is added to a document a computed name could be proposed but the user would be able to choose any name he wants). Our POV is that all Entities in XWiki should have a free name. * If this is agreed then the best solution for now it to consider "classname[number]" as an object name in EntityReference and to have temporary getters in ObjectReference to get the classname and the number (names for the getters to be decided: getIndex, getNumber, getPosition, etc). Of course getName() would perform the serialization. These 2 getters would be temporary and deprecated later on when the model accepts free form object names. This means that if we agree all Entities have a free name then there's no need to have "multivalue"/"indexed" reference names. Thanks -Vincent 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.

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

On Jan 19, 2010, at 4:36 PM, Anca Luca wrote:

Hi Vincent,

On 01/19/2010 05:11 PM, Vincent Massol wrote:

...

After discussing with Thomas we've reached the following conclusion:

* We need to decide if we agree that in the future we want Objects to have a free name (ie any name - when an object is added to a document a computed name could be proposed but the user would be able to choose any name he wants). Our POV is that all Entities in XWiki should have a free name.

* If this is agreed then the best solution for now it to consider "classname[number]" as an object name in EntityReference and to have temporary getters in ObjectReference to get the classname and the number (names for the getters to be decided: getIndex, getNumber, getPosition, etc). Of course getName() would perform the serialization. These 2 getters would be temporary and deprecated later on when the model accepts free form object names.

Yes, it's the same question as I was asking, but put otherwise, in a more future envisaging manner (I think we discussed about it like this at least 2 times on the development chat).

...

This means that if we agree all Entities have a free name then there's no need to have "multivalue"/"indexed" reference names.

However, if we implement it with a multivalued / indexed ref name now, with "temporary getters in ObjectReference to get the classname and the number" and then, when we decide if we agree on having free names we just switch that to a regular, non-indexed reference, what's the difference?

The difference is that if we want to support Entities without free names then the correct solution is different. For example a good solution in this case is to make EntityReference generic re the name (instead of String) and use xwiki-properties to convert from <T> to String in the generic serializer (or to any other serialization output). Thanks -Vincent

Otherwise put, does the implementation at this point actually depend on this decision?

Thanks, Anca

...

Thanks -Vincent

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.

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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs