Sounds good but I think I would prefer to make BlockReferenceCalculator a BlockReferenceResolver instead.
On Tue, Mar 11, 2014 at 10:54 AM, Denis Gervalle <[email protected]> wrote: > On Tue, Mar 11, 2014 at 10:33 AM, Denis Gervalle <[email protected]> wrote: > >> Hi devs, >> >> I am reviving this old vote, since I am implementing it (so your comment >> are urgently require if you are against), and so I may now provide correct >> answers to Vincent. >> >> I would like to add into platform a new BlockReference (EntityType.BLOCK) >> that have either a DocumentReference or an ObjectPropertyReference for >> parent or no parent at all. It will not have any impact on existing code, >> nor the rendering. It will simply allow any code to store and/or transmit a >> reference to a rendering block (mainly macros for now). >> >> The rules of how these references should be used will stay open, any code >> interacting with it will need to agree with any other module, on how to use >> the name of it. Even the uniqueness of the name will not need to be >> absolutely guaranteed, neither the way to find the block from the name >> (this may be impossible and unneeded). All this is left to the code using >> those references and interacting together. Said another way, it will be the >> association of an abstract name/id and a source containing the "named" >> block. >> >> I would like to also define a BlockReferenceCalculator interface that will >> allows calculating such references from either: >> - a rendering Block and a parent. >> - block id, a Map<String, String> of parameters, an optional content, and >> a parent >> - a macroId, a Map<String, String> of parameters, an optional content, >> and a parent >> >> The above could also be seen as some Resolver with different parameters, >> but while it would fit, I am not sure it is appropriate ? >> >> I expect to use this for keeping the link between a MacroBlock and a >> signature. For that purpose, the calculated id will not need to be >> necessarily unique for any MacroBlock (only unique one could be signed >> properly), and the block will never be reach from the reference, only >> reference comparison will be needed. >> > > Just forgot to mention, while in org.xwiki.model.reference, I would define > all this in the xwiki-platform-rendering-xwiki module. > > >> >> WDYT ? >> >> >> >> On Mon, Jul 22, 2013 at 1:46 PM, Vincent Massol <[email protected]>wrote: >> >>> Hi Denis, >>> >>> On Jul 22, 2013, at 9:20 AM, Denis Gervalle <[email protected]> wrote: >>> >>> > Hi devs, >>> > >>> > While building the new signed script solution with Thomas, we have the >>> need >>> > to create a new kind of entity references for macros. This will allow >>> us to >>> > keep reference to signed macros. >>> > >>> > Those references will have entityReference as parent, since macros may >>> be >>> > contained in document, but also in object properties. Currently we do >>> not >>> > need a syntax for those references, since these will only exists as >>> > objects. So, no string serializer is planned. >>> > >>> > So, we need to agree on creating macroReference that will have at this >>> > point a unique identifier (to be discussed later) and a parent that >>> could >>> > be either a documentReference or an objectPropertyReference. >>> > >>> > Here is my +1, >>> >>> +0. I'm putting 0 because I trust you but for me Macros are not Entity >>> References. >>> >>> Could you explain what this proposal will change for the current code? I >>> understand that you'll use it in the signed script code but I don't fully >>> grasp the implications for the existing code (like for example the >>> rendering modules). >>> >>> Also where do you plan to implement these Macro References? >>> >>> Thanks >>> -Vincent >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> >> >> -- >> Denis Gervalle >> SOFTEC sa - CEO >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > _______________________________________________ > 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
