[xwiki-devs] Resolve/Serialize entity references on the client side (JavaScript code)
Hi devs, While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d.... XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options: * add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side. There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better. Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it). Thanks, Marius
On Jun 18, 2012, at 8:57 PM, Marius Dumitru Florea wrote:
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d....
XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side.
There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it).
The only problem is maintenance and consistency, unless you generate the JS code from our model resolver/serializer written in java. Thanks -Vincent
On Mon, Jun 18, 2012 at 10:15 PM, Vincent Massol <vincent@massol.net> wrote:
On Jun 18, 2012, at 8:57 PM, Marius Dumitru Florea wrote:
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d....
XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side.
There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it).
The only problem is maintenance and consistency, unless you generate the JS code from our model resolver/serializer written in java.
The JavaScript code is not generated, it's written by hand, but I count on the fact that the code from xwiki-platform-model#reference is pretty stable and is not going to change very often. Of course, I commit to update the JavaScript code whenever there are important changes on the server side. Thanks, Marius
Thanks -Vincent _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d....
XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side.
There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it).
Counting on Ajax call each time you need to parse/serialize a reference sounds pretty bad for performances anyway so better having a client side implementation. I agree with Vincent that it's going to be some work to maintain it but I don't see much choice. What I see in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... is very different from the Java modele API, If we go for having a JS version of the reference API I think I would prefer to start something a lot more in sync (even if partial) grouped with the Java modele module under the same parent or something on git/maven so that it's clear that they are supposed to be in sync as much as possible. Not sure how we can package the JS lib, zip ? It's a lot easier to keep in synch two things that look like each other.
Thanks, Marius _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d....
XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side.
There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it).
Counting on Ajax call each time you need to parse/serialize a reference sounds pretty bad for performances anyway so better having a client side implementation. I agree with Vincent that it's going to be some work to maintain it but I don't see much choice.
What I see in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... is very different from the Java modele API, If we go for having a JS version of the reference API I think I would prefer to start something a lot more in sync (even if partial) grouped with the Java modele module under the same parent or something on git/maven so that it's clear that they are supposed to be in sync as much as possible. Not sure how we can package the JS lib, zip ? It's a lot easier to keep in synch two things that look like each other.
Sorry was not looking at the right new methods. Still I think it would be nice to put the Java and JS versions under the same parent if possible.
Thanks, Marius _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
On Tue, Jun 19, 2012 at 9:37 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d....
XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side.
There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it).
Counting on Ajax call each time you need to parse/serialize a reference sounds pretty bad for performances anyway so better having a client side implementation. I agree with Vincent that it's going to be some work to maintain it but I don't see much choice.
What I see in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... is very different from the Java modele API, If we go for having a JS version of the reference API I think I would prefer to start something a lot more in sync (even if partial) grouped with the Java modele module under the same parent or something on git/maven so that it's clear that they are supposed to be in sync as much as possible. Not sure how we can package the JS lib, zip ? It's a lot easier to keep in synch two things that look like each other.
Sorry was not looking at the right new methods. Still I think it would be nice to put the Java and JS versions under the same parent if possible.
This API does not seems to have the concept of different kind of resolver/serializer (current, compact, etc.). Is there something I did not seen ?
Thanks, Marius _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
On Tue, Jun 19, 2012 at 10:42 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 9:37 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d....
XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side.
There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it).
Counting on Ajax call each time you need to parse/serialize a reference sounds pretty bad for performances anyway so better having a client side implementation. I agree with Vincent that it's going to be some work to maintain it but I don't see much choice.
What I see in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... is very different from the Java modele API, If we go for having a JS version of the reference API I think I would prefer to start something a lot more in sync (even if partial) grouped with the Java modele module under the same parent or something on git/maven so that it's clear that they are supposed to be in sync as much as possible. Not sure how we can package the JS lib, zip ? It's a lot easier to keep in synch two things that look like each other.
Sorry was not looking at the right new methods. Still I think it would be nice to put the Java and JS versions under the same parent if possible.
The actual API is https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... with unit tests in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... . I'm fine with moving under the same parent, but I'm not sure how. I see that skins generate a zip which is then unpacked and integrated in the war. We could probably do the same.
This API does not seems to have the concept of different kind of resolver/serializer (current, compact, etc.). Is there something I did not seen ?
It doesn't. We don't have a component manager on the client side so it was easier/quicker for me write a simple resolver/serializer (based on the Abstract/Default entity reference resolver/serializer from xwiki-platform-model) which parses/serializes only what it gets. The rest can be added on top of this: * after you resolve a string entity reference, in your code you can add the missing entity reference parts or replace the empty ones. We can write something generic but I didn't need it so far * in order to serialize relative to another entity reference I added XWiki.EntityReference#relativeTo which removes common entity reference parts Thanks, Marius
Thanks, Marius _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi, It's good to have those APIs client side as well. Concerning the location, it doesn't not belong in resources/uicomponents/model/entityReference.js (it's not an UI component) ; maybe in resources/model/entityReference.js ? Jerome On Tue, Jun 19, 2012 at 9:57 AM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 10:42 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 9:37 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d....
XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side.
There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it).
Counting on Ajax call each time you need to parse/serialize a reference sounds pretty bad for performances anyway so better having a client side implementation. I agree with Vincent that it's going to be some work to maintain it but I don't see much choice.
What I see in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... is very different from the Java modele API, If we go for having a JS version of the reference API I think I would prefer to start something a lot more in sync (even if partial) grouped with the Java modele module under the same parent or something on git/maven so that it's clear that they are supposed to be in sync as much as possible. Not sure how we can package the JS lib, zip ? It's a lot easier to keep in synch two things that look like each other.
Sorry was not looking at the right new methods. Still I think it would be nice to put the Java and JS versions under the same parent if possible.
The actual API is https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... with unit tests in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... .
I'm fine with moving under the same parent, but I'm not sure how. I see that skins generate a zip which is then unpacked and integrated in the war. We could probably do the same.
This API does not seems to have the concept of different kind of resolver/serializer (current, compact, etc.). Is there something I did not seen ?
It doesn't. We don't have a component manager on the client side so it was easier/quicker for me write a simple resolver/serializer (based on the Abstract/Default entity reference resolver/serializer from xwiki-platform-model) which parses/serializes only what it gets. The rest can be added on top of this:
* after you resolve a string entity reference, in your code you can add the missing entity reference parts or replace the empty ones. We can write something generic but I didn't need it so far * in order to serialize relative to another entity reference I added XWiki.EntityReference#relativeTo which removes common entity reference parts
Thanks, Marius
Thanks, Marius _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
+1 Although it's never feels good implementing logic twice, converting this from java with gwt would probably introduce more problems than it solves and realistically I can't imagine this ever actually changing. It would be nicer if there was a test to compare the two or perhaps comments at each implementation warning the maintainer of the other. Caleb On 06/19/2012 03:57 AM, Marius Dumitru Florea wrote:
On Tue, Jun 19, 2012 at 10:42 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 9:37 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d....
XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side.
There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it).
Counting on Ajax call each time you need to parse/serialize a reference sounds pretty bad for performances anyway so better having a client side implementation. I agree with Vincent that it's going to be some work to maintain it but I don't see much choice.
What I see in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... is very different from the Java modele API, If we go for having a JS version of the reference API I think I would prefer to start something a lot more in sync (even if partial) grouped with the Java modele module under the same parent or something on git/maven so that it's clear that they are supposed to be in sync as much as possible. Not sure how we can package the JS lib, zip ? It's a lot easier to keep in synch two things that look like each other.
Sorry was not looking at the right new methods. Still I think it would be nice to put the Java and JS versions under the same parent if possible.
The actual API is https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... with unit tests in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... .
I'm fine with moving under the same parent, but I'm not sure how. I see that skins generate a zip which is then unpacked and integrated in the war. We could probably do the same.
This API does not seems to have the concept of different kind of resolver/serializer (current, compact, etc.). Is there something I did not seen ?
It doesn't. We don't have a component manager on the client side so it was easier/quicker for me write a simple resolver/serializer (based on the Abstract/Default entity reference resolver/serializer from xwiki-platform-model) which parses/serializes only what it gets. The rest can be added on top of this:
* after you resolve a string entity reference, in your code you can add the missing entity reference parts or replace the empty ones. We can write something generic but I didn't need it so far * in order to serialize relative to another entity reference I added XWiki.EntityReference#relativeTo which removes common entity reference parts
Thanks, Marius
Thanks, Marius _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On 06/19/2012 11:59 PM, Caleb James DeLisle wrote:
+1
Although it's never feels good implementing logic twice, converting this from java with gwt would probably introduce more problems than it solves and realistically I can't imagine this ever actually changing.
It would be nicer if there was a test to compare the two or perhaps comments at each implementation warning the maintainer of the other.
We should write some more Jasmine tests for JavaScript, and having the same tests both for the Java and the JavaScript components would be a major step towards validating the compatibility of the implementations.
Caleb
On 06/19/2012 03:57 AM, Marius Dumitru Florea wrote:
On Tue, Jun 19, 2012 at 10:42 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 9:37 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
Hi devs,
While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an API to resolve and serialize entity references on the client side (JavaScript code). See https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d....
XWiki Explorer tree has an input displayed at the bottom where you can type a _pseudo_ entity reference which is parsed and the specified entity is selected in the tree. The basic problem (very simplified) was that this reference was parsed on the client side and the parsing code did not handle special characters in entity name (no escaping). Of course, I had to options:
* add a service (REST?) to resolve/serialize the reference on the server or * (as I did) port part of the code from xwiki-platform-model (with unit tests!) to JavaScript to be able to resolve/serialize entity references on the client side.
There are pros and cons for each option but for me the main reason was that it is painful to modify xwikiexplorer.js to make AJAX requests each time you type into that input box (the tree node is selected as you type). An almost complete rewrite was needed and since we're looking to replace that tree I thought the second option was better.
Would be great if you can review my commit. I'm interested in the API naming and places where I put the JS code. Also, I'm not sure where to document the new API (that is if no one is against it).
Counting on Ajax call each time you need to parse/serialize a reference sounds pretty bad for performances anyway so better having a client side implementation. I agree with Vincent that it's going to be some work to maintain it but I don't see much choice.
What I see in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... is very different from the Java modele API, If we go for having a JS version of the reference API I think I would prefer to start something a lot more in sync (even if partial) grouped with the Java modele module under the same parent or something on git/maven so that it's clear that they are supposed to be in sync as much as possible. Not sure how we can package the JS lib, zip ? It's a lot easier to keep in synch two things that look like each other.
Sorry was not looking at the right new methods. Still I think it would be nice to put the Java and JS versions under the same parent if possible.
The actual API is https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... with unit tests in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... .
I'm fine with moving under the same parent, but I'm not sure how. I see that skins generate a zip which is then unpacked and integrated in the war. We could probably do the same.
This API does not seems to have the concept of different kind of resolver/serializer (current, compact, etc.). Is there something I did not seen ?
It doesn't. We don't have a component manager on the client side so it was easier/quicker for me write a simple resolver/serializer (based on the Abstract/Default entity reference resolver/serializer from xwiki-platform-model) which parses/serializes only what it gets. The rest can be added on top of this:
* after you resolve a string entity reference, in your code you can add the missing entity reference parts or replace the empty ones. We can write something generic but I didn't need it so far * in order to serialize relative to another entity reference I added XWiki.EntityReference#relativeTo which removes common entity reference parts
Thanks, Marius
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Wed, Jun 20, 2012 at 9:37 PM, Sergiu Dumitriu <sergiu@xwiki.com> wrote:
On 06/19/2012 11:59 PM, Caleb James DeLisle wrote:
+1
Although it's never feels good implementing logic twice, converting this from java with gwt would probably introduce more problems than it solves and realistically I can't imagine this ever actually changing.
It would be nicer if there was a test to compare the two or perhaps comments at each implementation warning the maintainer of the other.
We should write some more Jasmine tests for JavaScript, and having the same tests both for the Java and the JavaScript components would be a major step towards validating the compatibility of the implementations.
In https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik... there are all the tests from https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik... and testResolveDocumentReference from https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik... (I just didn't have the patience to port all of the resolver tests but I plan to continue it). Thanks, Marius
Caleb
On 06/19/2012 03:57 AM, Marius Dumitru Florea wrote:
On Tue, Jun 19, 2012 at 10:42 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 9:37 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote: > > Hi devs, > > While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an > API to resolve and serialize entity references on the client side > (JavaScript code). See > > https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d.... > > XWiki Explorer tree has an input displayed at the bottom where you > can > type a _pseudo_ entity reference which is parsed and the specified > entity is selected in the tree. The basic problem (very simplified) > was that this reference was parsed on the client side and the parsing > code did not handle special characters in entity name (no escaping). > Of course, I had to options: > > * add a service (REST?) to resolve/serialize the reference on the > server or > * (as I did) port part of the code from xwiki-platform-model (with > unit tests!) to JavaScript to be able to resolve/serialize entity > references on the client side. > > There are pros and cons for each option but for me the main reason > was > that it is painful to modify xwikiexplorer.js to make AJAX requests > each time you type into that input box (the tree node is selected as > you type). An almost complete rewrite was needed and since we're > looking to replace that tree I thought the second option was better. > > Would be great if you can review my commit. I'm interested in the API > naming and places where I put the JS code. Also, I'm not sure where > to > document the new API (that is if no one is against it).
Counting on Ajax call each time you need to parse/serialize a reference sounds pretty bad for performances anyway so better having a client side implementation. I agree with Vincent that it's going to be some work to maintain it but I don't see much choice.
What I see in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... is very different from the Java modele API, If we go for having a JS version of the reference API I think I would prefer to start something a lot more in sync (even if partial) grouped with the Java modele module under the same parent or something on git/maven so that it's clear that they are supposed to be in sync as much as possible. Not sure how we can package the JS lib, zip ? It's a lot easier to keep in synch two things that look like each other.
Sorry was not looking at the right new methods. Still I think it would be nice to put the Java and JS versions under the same parent if possible.
The actual API is
https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... with unit tests in
https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... .
I'm fine with moving under the same parent, but I'm not sure how. I see that skins generate a zip which is then unpacked and integrated in the war. We could probably do the same.
This API does not seems to have the concept of different kind of resolver/serializer (current, compact, etc.). Is there something I did not seen ?
It doesn't. We don't have a component manager on the client side so it was easier/quicker for me write a simple resolver/serializer (based on the Abstract/Default entity reference resolver/serializer from xwiki-platform-model) which parses/serializes only what it gets. The rest can be added on top of this:
* after you resolve a string entity reference, in your code you can add the missing entity reference parts or replace the empty ones. We can write something generic but I didn't need it so far * in order to serialize relative to another entity reference I added XWiki.EntityReference#relativeTo which removes common entity reference parts
Thanks, Marius
-- Sergiu Dumitriu http://purl.org/net/sergiu/
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
Caleb James DeLisle -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol