On Jan 21, 2010, at 2:10 PM, Anca Luca wrote: > 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.
Personally I find it more confusing that the previous suggestion. When you read such a string it's hard to parse visually and you don't know what is the wiki, space, page since the same separators are used. I don't have any strong opinion. -Vincent > > +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-tp4348315p4414596.html >>>>>> 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
