Re: [xwiki-devs] Resolve/Serialize entity references on the client side (JavaScript code)

+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