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/cfa8ec3315a32fed875949ff21a5…. 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).

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/cfa8ec3315a32fed875949ff21a5…. 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 _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

On Tue, Jun 19, 2012 at 9:37 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne > <thomas.mortagne(a)xwiki.com> wrote: >> On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea >> <mariusdumitru.florea(a)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/cfa8ec3315a32fed875949ff21a5…. >>> >>> 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/cfa8ec3315a32fed875949ff21a5… >> 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 ?

-- Thomas Mortagne _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

+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(a)xwiki.com> wrote: >> >> On Tue, Jun 19, 2012 at 9:37 AM, Thomas Mortagne >> <thomas.mortagne(a)xwiki.com> wrote: >>> >>> On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne >>> <thomas.mortagne(a)xwiki.com> wrote: >>>> >>>> On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea >>>> <mariusdumitru.florea(a)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/cfa8ec3315a32fed875949ff21a5…. >>>>> >>>>> 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/cfa8ec3315a32fed875949ff21a5… >>>> 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/cfa8ec3315a32fed875949ff21a5… > with unit tests in > > https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5… > . > > 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