[xwiki-devs] JSON Velocity Tool
Hi devs, Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes: 1. Use Jackson [2] instead of json-lib [3] because it has a more recent release 2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString Reply quickly if you are against it. Thanks, Marius [1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release
Isn't json-lib already a dependency available, should we use another one ?
2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :) Thanks -Vincent
2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it. Thanks, Marius
Thanks -Vincent
2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mar 9, 2012, at 3:26 PM, Marius Dumitru Florea wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
I'm not against changing the json lib we use though. (just to be clear). Thanks -Vincent
Thanks, Marius
Thanks -Vincent
2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
Jackson is considered faster, by several orders. Some articles/threads that talks about it : - http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in... - http://www.sencha.com/forum/archive/index.php/t-94883.html It can be a case for Jackson : if we are to use that tool for generating livetable values, performance is a big deal. my 2 cents Jerome
Thanks, Marius
Thanks -Vincent
2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
On Fri, Mar 9, 2012 at 4:47 PM, Jerome Velociter <[email protected]> wrote:
On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
Jackson is considered faster, by several orders. Some articles/threads that talks about it : - http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in... - http://www.sencha.com/forum/archive/index.php/t-94883.html
It can be a case for Jackson : if we are to use that tool for generating livetable values, performance is a big deal.
That's my use case. I want to refactor the macros from XWiki.LiveTableResultsMacros to generate the "JSON" in memory (using actually plain Java data types like maps and lists/arrays) so that I can adjust it before the response is send to the client. This way I can avoid duplicating the code from XWiki.LiveTableResultsMacros just to add a new property to the generated JSON or to modify the value of an existing property. Since json-lib is used only in xwiki-platform-oldcore by the package plugin I think it's fine to: * use Jackson in JSONTool * when we refactor the package plugin into a component (if we still needed it at that point) we can also change the code to use Jackson. I can add a comment in the pom for this so that we don't forget about it. WDYT? I'm +1 for this. Thanks, Marius
my 2 cents
Jerome
Thanks, Marius
Thanks -Vincent
2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Mar 9, 2012 at 4:08 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:47 PM, Jerome Velociter <[email protected]> wrote:
On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
Jackson is considered faster, by several orders. Some articles/threads that talks about it : - http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in... - http://www.sencha.com/forum/archive/index.php/t-94883.html
It can be a case for Jackson : if we are to use that tool for generating livetable values, performance is a big deal.
That's my use case. I want to refactor the macros from XWiki.LiveTableResultsMacros to generate the "JSON" in memory (using actually plain Java data types like maps and lists/arrays) so that I can adjust it before the response is send to the client. This way I can avoid duplicating the code from XWiki.LiveTableResultsMacros just to add a new property to the generated JSON or to modify the value of an existing property.
And as a nice addition we will finally get proper escaping of liverable JSON values...
Since json-lib is used only in xwiki-platform-oldcore by the package plugin I think it's fine to:
* use Jackson in JSONTool * when we refactor the package plugin into a component (if we still needed it at that point) we can also change the code to use Jackson. I can add a comment in the pom for this so that we don't forget about it.
WDYT?
I'm +1 for this.
Thanks, Marius
my 2 cents
Jerome
Thanks, Marius
Thanks -Vincent
2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mar 9, 2012, at 4:08 PM, Marius Dumitru Florea wrote:
On Fri, Mar 9, 2012 at 4:47 PM, Jerome Velociter <[email protected]> wrote:
On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
Jackson is considered faster, by several orders. Some articles/threads that talks about it : - http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in... - http://www.sencha.com/forum/archive/index.php/t-94883.html
It can be a case for Jackson : if we are to use that tool for generating livetable values, performance is a big deal.
That's my use case. I want to refactor the macros from XWiki.LiveTableResultsMacros to generate the "JSON" in memory (using actually plain Java data types like maps and lists/arrays) so that I can adjust it before the response is send to the client. This way I can avoid duplicating the code from XWiki.LiveTableResultsMacros just to add a new property to the generated JSON or to modify the value of an existing property.
Since json-lib is used only in xwiki-platform-oldcore by the package plugin I think it's fine to:
* use Jackson in JSONTool * when we refactor the package plugin into a component (if we still needed it at that point) we can also change the code to use Jackson. I can add a comment in the pom for this so that we don't forget about it.
WDYT?
I don't understand. Why not use Jackson for the Package plugin? How hard is this? Both libs are not doing the same thing, is that the problem? There's no API for what is done in the package plugin? (btw why do we need json in the package plugin? :)) Thanks -Vincent
I'm +1 for this.
Thanks, Marius
my 2 cents
Jerome
Thanks, Marius
Thanks -Vincent
2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
On Fri, Mar 9, 2012 at 16:08, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Mar 9, 2012 at 4:47 PM, Jerome Velociter <[email protected]> wrote:
On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd
like
to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
Jackson is considered faster, by several orders. Some articles/threads that talks about it : - http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in... - http://www.sencha.com/forum/archive/index.php/t-94883.html
It can be a case for Jackson : if we are to use that tool for generating livetable values, performance is a big deal.
That's my use case. I want to refactor the macros from XWiki.LiveTableResultsMacros to generate the "JSON" in memory (using actually plain Java data types like maps and lists/arrays) so that I can adjust it before the response is send to the client. This way I can avoid duplicating the code from XWiki.LiveTableResultsMacros just to add a new property to the generated JSON or to modify the value of an existing property.
Since json-lib is used only in xwiki-platform-oldcore by the package plugin I think it's fine to:
* use Jackson in JSONTool * when we refactor the package plugin into a component (if we still needed it at that point) we can also change the code to use Jackson. I can add a comment in the pom for this so that we don't forget about it.
WDYT?
What about groovy ? the JSONBuilder provided by json-lib is nice to have, and is one of the motivation of the initial thread. I am not asking for annoying you, we use all that already in many sites. I am not against improving, but we should also be careful to not break existing stuffs.
I'm +1 for this.
Thanks, Marius
my 2 cents
Jerome
Thanks, Marius
Thanks -Vincent
2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mar 9, 2012, at 4:51 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 16:08, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Mar 9, 2012 at 4:47 PM, Jerome Velociter <[email protected]> wrote:
On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
> Hi devs, > > Some time ago Jerome Velociter raised a vote [1] for adding a JSON > Velocity Tool. The vote passed but the tool wasn't committed. I'd
like
> to do it know (for 4.0M1) with two changes: > > 1. Use Jackson [2] instead of json-lib [3] because it has a more recent > release >
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
Jackson is considered faster, by several orders. Some articles/threads that talks about it : - http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in... - http://www.sencha.com/forum/archive/index.php/t-94883.html
It can be a case for Jackson : if we are to use that tool for generating livetable values, performance is a big deal.
That's my use case. I want to refactor the macros from XWiki.LiveTableResultsMacros to generate the "JSON" in memory (using actually plain Java data types like maps and lists/arrays) so that I can adjust it before the response is send to the client. This way I can avoid duplicating the code from XWiki.LiveTableResultsMacros just to add a new property to the generated JSON or to modify the value of an existing property.
Since json-lib is used only in xwiki-platform-oldcore by the package plugin I think it's fine to:
* use Jackson in JSONTool * when we refactor the package plugin into a component (if we still needed it at that point) we can also change the code to use Jackson. I can add a comment in the pom for this so that we don't forget about it.
WDYT?
What about groovy ? the JSONBuilder provided by json-lib is nice to have, and is one of the motivation of the initial thread. I am not asking for annoying you, we use all that already in many sites. I am not against improving, but we should also be careful to not break existing stuffs.
Groovy has a built json parser. Thanks -Vincent
I'm +1 for this.
Thanks, Marius
my 2 cents
Jerome
Thanks, Marius
Thanks -Vincent
> 2. Add only the toJSON method for now because we can use > $escapetool.javascript to accomplish the same result as toValueString > > Reply quickly if you are against it. > > Thanks, > Marius > > [1] http://www.mail-archive.com/[email protected]/msg11395.html > [2] http://jackson.codehaus.org/ > [3] http://json-lib.sourceforge.net/
On Fri, Mar 9, 2012 at 4:51 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 9, 2012 at 16:08, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Mar 9, 2012 at 4:47 PM, Jerome Velociter <[email protected]> wrote:
On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < [email protected]> wrote:
> Hi devs, > > Some time ago Jerome Velociter raised a vote [1] for adding a JSON > Velocity Tool. The vote passed but the tool wasn't committed. I'd
like
> to do it know (for 4.0M1) with two changes: > > 1. Use Jackson [2] instead of json-lib [3] because it has a more recent > release >
Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
Jackson is considered faster, by several orders. Some articles/threads that talks about it : - http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in... - http://www.sencha.com/forum/archive/index.php/t-94883.html
It can be a case for Jackson : if we are to use that tool for generating livetable values, performance is a big deal.
That's my use case. I want to refactor the macros from XWiki.LiveTableResultsMacros to generate the "JSON" in memory (using actually plain Java data types like maps and lists/arrays) so that I can adjust it before the response is send to the client. This way I can avoid duplicating the code from XWiki.LiveTableResultsMacros just to add a new property to the generated JSON or to modify the value of an existing property.
Since json-lib is used only in xwiki-platform-oldcore by the package plugin I think it's fine to:
* use Jackson in JSONTool * when we refactor the package plugin into a component (if we still needed it at that point) we can also change the code to use Jackson. I can add a comment in the pom for this so that we don't forget about it.
WDYT?
What about groovy ? the JSONBuilder provided by json-lib is nice to have, and is one of the motivation of the initial thread. I am not asking for annoying you, we use all that already in many sites. I am not against improving, but we should also be careful to not break existing stuffs.
I'm not sure what's the problem/how groovy changes the picture here. Right now json-lib is bundled with XWiki and used internally, but not exposed. I don't think bundled jars should be assumed stable over time. Do we have a rule for this ? In any case that's not good enough a reason to ditch jackson in favor of json-lib, IMHO. Worse case, it's an argument in favor of keeping json-lib in the classpath in addition to whatever other lib we decide to use - should we decide to use something else than json-lib.
I'm +1 for this.
Thanks, Marius
my 2 cents
Jerome
Thanks, Marius
Thanks -Vincent
> 2. Add only the toJSON method for now because we can use > $escapetool.javascript to accomplish the same result as toValueString > > Reply quickly if you are against it. > > Thanks, > Marius > > [1] http://www.mail-archive.com/[email protected]/msg11395.html > [2] http://jackson.codehaus.org/ > [3] http://json-lib.sourceforge.net/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
On Fri, Mar 9, 2012 at 17:17, Jerome Velociter <[email protected]>wrote:
On Fri, Mar 9, 2012 at 4:51 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 9, 2012 at 16:08, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Mar 9, 2012 at 4:47 PM, Jerome Velociter <[email protected]
wrote:
On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote:
> On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < > [email protected]> wrote: > >> Hi devs, >> >> Some time ago Jerome Velociter raised a vote [1] for adding a JSON >> Velocity Tool. The vote passed but the tool wasn't committed. I'd
like
>> to do it know (for 4.0M1) with two changes: >> >> 1. Use Jackson [2] instead of json-lib [3] because it has a more recent >> release >> > > Isn't json-lib already a dependency available, should we use another one ?
+1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
Jackson is considered faster, by several orders. Some articles/threads that talks about it : -
http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in...
- http://www.sencha.com/forum/archive/index.php/t-94883.html
It can be a case for Jackson : if we are to use that tool for generating livetable values, performance is a big deal.
That's my use case. I want to refactor the macros from XWiki.LiveTableResultsMacros to generate the "JSON" in memory (using actually plain Java data types like maps and lists/arrays) so that I can adjust it before the response is send to the client. This way I can avoid duplicating the code from XWiki.LiveTableResultsMacros just to add a new property to the generated JSON or to modify the value of an existing property.
Since json-lib is used only in xwiki-platform-oldcore by the package plugin I think it's fine to:
* use Jackson in JSONTool * when we refactor the package plugin into a component (if we still needed it at that point) we can also change the code to use Jackson. I can add a comment in the pom for this so that we don't forget about it.
WDYT?
What about groovy ? the JSONBuilder provided by json-lib is nice to have, and is one of the motivation of the initial thread. I am not asking for annoying you, we use all that already in many sites. I am not against improving, but we should also be careful to not break existing stuffs.
I'm not sure what's the problem/how groovy changes the picture here. Right now json-lib is bundled with XWiki and used internally, but not exposed. I don't think bundled jars should be assumed stable over time. Do we have a rule for this ?
In any case that's not good enough a reason to ditch jackson in favor of json-lib, IMHO. Worse case, it's an argument in favor of keeping json-lib in the classpath in addition to whatever other lib we decide to use - should we decide to use something else than json-lib.
That was my concern, you expressed yourself better than I have. The question is simply, is Jackson so much better that we want to have both, or drop some compatibility.
I'm +1 for this.
Thanks, Marius
my 2 cents
Jerome
Thanks, Marius
Thanks -Vincent > > >> 2. Add only the toJSON method for now because we can use >> $escapetool.javascript to accomplish the same result as
toValueString
>> >> Reply quickly if you are against it. >> >> Thanks, >> Marius >> >> [1] http://www.mail-archive.com/[email protected]/msg11395.html >> [2] http://jackson.codehaus.org/ >> [3] http://json-lib.sourceforge.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Fri, Mar 9, 2012 at 5:21 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 9, 2012 at 17:17, Jerome Velociter <[email protected]>wrote:
On Fri, Mar 9, 2012 at 4:51 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 9, 2012 at 16:08, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Mar 9, 2012 at 4:47 PM, Jerome Velociter <[email protected]
wrote:
On Fri, Mar 9, 2012 at 3:26 PM, Marius Dumitru Florea <[email protected]> wrote:
On Fri, Mar 9, 2012 at 4:10 PM, Vincent Massol <[email protected]> wrote: > > On Mar 9, 2012, at 3:02 PM, Denis Gervalle wrote: > >> On Fri, Mar 9, 2012 at 14:54, Marius Dumitru Florea < >> [email protected]> wrote: >> >>> Hi devs, >>> >>> Some time ago Jerome Velociter raised a vote [1] for adding a JSON >>> Velocity Tool. The vote passed but the tool wasn't committed. I'd like >>> to do it know (for 4.0M1) with two changes: >>> >>> 1. Use Jackson [2] instead of json-lib [3] because it has a more recent >>> release >>> >> >> Isn't json-lib already a dependency available, should we use another one ? > > +1 to use only one json lib in xwiki! :)
Fine.. since json-lib is already used in public API (com.xpn.xwiki.plugin.packaging.PackageAPI) I'll stick with it.
Jackson is considered faster, by several orders. Some articles/threads that talks about it : -
http://www.lshift.net/blog/2011/12/28/benchmarking-simple-json-generation-in...
- http://www.sencha.com/forum/archive/index.php/t-94883.html
It can be a case for Jackson : if we are to use that tool for generating livetable values, performance is a big deal.
That's my use case. I want to refactor the macros from XWiki.LiveTableResultsMacros to generate the "JSON" in memory (using actually plain Java data types like maps and lists/arrays) so that I can adjust it before the response is send to the client. This way I can avoid duplicating the code from XWiki.LiveTableResultsMacros just to add a new property to the generated JSON or to modify the value of an existing property.
Since json-lib is used only in xwiki-platform-oldcore by the package plugin I think it's fine to:
* use Jackson in JSONTool * when we refactor the package plugin into a component (if we still needed it at that point) we can also change the code to use Jackson. I can add a comment in the pom for this so that we don't forget about it.
WDYT?
What about groovy ? the JSONBuilder provided by json-lib is nice to have, and is one of the motivation of the initial thread. I am not asking for annoying you, we use all that already in many sites. I am not against improving, but we should also be careful to not break existing stuffs.
I'm not sure what's the problem/how groovy changes the picture here. Right now json-lib is bundled with XWiki and used internally, but not exposed. I don't think bundled jars should be assumed stable over time. Do we have a rule for this ?
In any case that's not good enough a reason to ditch jackson in favor of json-lib, IMHO. Worse case, it's an argument in favor of keeping json-lib in the classpath in addition to whatever other lib we decide to use - should we decide to use something else than json-lib.
That was my concern, you expressed yourself better than I have. The question is simply, is Jackson so much better that we want to have both, or drop some compatibility.
Personnally I don't have too strong feelings, however, I think that : * Good performance of the livetable is important. JSON serialization time might not be that much a big deal compared to SQL time - but in the end once you got rid of big bottlenecks, the performance of every link in the chain matters. * There is support for jackson in Restlet via an extension. This could help us improve performance of our REST API for JSON payloads/responses. * Jackson seems more active So in the end I tend to be in favor of jackson over json-lib. There is also GSON that could be investigated. Personnally I've never worked with it/don't know much about it. Jerome
I'm +1 for this.
Thanks, Marius
my 2 cents
Jerome
Thanks, Marius
> > Thanks > -Vincent >> >> >>> 2. Add only the toJSON method for now because we can use >>> $escapetool.javascript to accomplish the same result as
toValueString
>>> >>> Reply quickly if you are against it. >>> >>> Thanks, >>> Marius >>> >>> [1] http://www.mail-archive.com/[email protected]/msg11395.html >>> [2] http://jackson.codehaus.org/ >>> [3] http://json-lib.sourceforge.net/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
+1 On Fri, Mar 9, 2012 at 2:54 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release 2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 03/09/2012 08:54 AM, Marius Dumitru Florea wrote:
Hi devs,
Some time ago Jerome Velociter raised a vote [1] for adding a JSON Velocity Tool. The vote passed but the tool wasn't committed. I'd like to do it know (for 4.0M1) with two changes:
1. Use Jackson [2] instead of json-lib [3] because it has a more recent release 2. Add only the toJSON method for now because we can use $escapetool.javascript to accomplish the same result as toValueString
Not true, $escapetool.javascript always escapes both " and ' in a string, and this isn't valid JSON, according to jsonlint.com (and the JSON specification on json.org): {"key" : "value with escaped \" and esaped \' is wrong"} So far I used $escapetool.javascript($var).replace('\''', '''') to fix this.
Reply quickly if you are against it.
Thanks, Marius
[1] http://www.mail-archive.com/[email protected]/msg11395.html [2] http://jackson.codehaus.org/ [3] http://json-lib.sourceforge.net/
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (6)
-
Denis Gervalle -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol