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? I think the more notations... the harder is to see the code and understand it.
wiki:Space.Page:object.property 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
