Hi devs, After discussion with Thomas, I have finally decided to stick more with the model and define a BlockReference as a reference to a structured part of the content of a document or an object property. With the additional provision that the meaning of block references depends on their usage, may not be unique and are not necessarily a way to reach the referenced instance. We may have different kind of block references, for different purposes (for example identifying a header in the content, linking signature to macro block, etc...). This reference will be added into xwiki-platform-model, since it is general purpose, and since it is linked with the an avoidable change in model to add the new EntityType.BLOCK.
A BlockReferenceResolver may resolve a reference from the referenced instance or another representation into a validated BlockReference object. It will be also defined in xwiki-platform-model without any ParametrizedType helper, and no default implementation will be provided, since the meaning of a block reference is not application wide. Finally, for the signature purpose, a SignedBlockBlockReferenceResolver will be defined in a platform-rendering sub-module for resolving block reference that link macro blocks with signatures. I hope this will meet your agreement since it is already implemented. Please comment fast if you strongly disagree. On Thu, Mar 13, 2014 at 6:40 PM, Thomas Mortagne <[email protected]>wrote: > 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 > -- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
