+1 On Fri, Mar 14, 2014 at 10:55 AM, Denis Gervalle <[email protected]> wrote: > 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
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
