On Tue, Jan 19, 2010 at 12:50, Anca Luca <[email protected]> wrote: > 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.
Sure but that's not the point, i'm just comparing your two proposal and iv) has less chance to point to something than iii) > > 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. Yes that's what is said. > > 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 >>> >> >> >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
