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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
