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