[xwiki-devs] [VOTE] Create reference to macros
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, -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mon, 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.
+1 for the concept of having a reference for this but I would suggest a more generic BlockReference instead of just a MacroReference since we have other blocks that already have the concept of id like the headings.
Here is my +1,
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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
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. 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
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
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
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
+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
+0 Thanks, Marius On Fri, Mar 14, 2014 at 11: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
participants (4)
-
Denis Gervalle -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol