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
<thomas.mortagne(a)xwiki.com>wrote;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 <dgl(a)softec.lu> wrote:
  On Tue, Mar 11, 2014 at 10:33 AM, Denis Gervalle
<dgl(a)softec.lu> 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 <vincent(a)massol.net 
wrote:
>
>> Hi Denis,
>>
>> On Jul 22, 2013, at 9:20 AM, Denis Gervalle <dgl(a)softec.lu> 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
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs
 
 --
 Denis Gervalle
 SOFTEC sa - CEO
 
 
 --
 Denis Gervalle
 SOFTEC sa - CEO
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs  
 --
 Thomas Mortagne
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs