A bit late to the game but can't we pass a cannonicalized absolute string to the JS ? eg: wiki:space.sp\.ace.sp\\ace.page and then just warn the js devs that they should use functions to manipulate the string representation instead of hacking it manually ?

That's what nodejs does for URLs and I will say without reservation that the user-friendlyness of their their URL parsing API is not even compatible to the disaster that was java.net.URL. On 26/08/15 17:36, Guillaume "Louis-Marie" Delhumeau wrote: > I don't really understand the solution 2. > > We already have an EntityReference class in entityReference.js, with a > string serializer and a string parser. > > If we use a JSON format to describe a reference, we will still have to > parse it to create an EntityReference object, and this parser does not > exist yet. > > So what is the benefit? > > I only see drawbacks: > - A JSON reference is a lot more verbose. > - From the java side, we need to serialize the reference to a JSON > representation which is probably more costly than serializing to a string. > - We use string representations in a lot of places, and suddenly we should > use JSON but only when we do JavaScript... > > So +1 for the solution 1. > > In any case, it seems a good idea to use references in JS code. > > Thanks, > Guillaume > > 2015-08-06 14:25 GMT+02:00 Eduard Moraru : > >> I agree with Thomas that it would be best to use EntityReference -> JSON as >> much as possible (when passing the reference from velocity to javascript, >> server-side), however, man times when you need a reference you also end up >> building a new reference (on the client-side, i.e. javascript) so we can`t >> really avoid having a strong javascript EntityReference API + >> serializer/resolver. >> >> Also, making a HTTP request from JS to resolve a string reference on the >> server (and getting a JSON result) is not really an option IMO (specially >> if you do that a lot). >> >> So +1 to using reference in javascript code. >> >> Thanks, >> Eduard >> >> On Thu, Jul 30, 2015 at 11:50 AM, Thomas Mortagne < >> thomas.mortagne(a)xwiki.com >>> wrote: >> >>> Direct EntityReference -> JSON serialisation would provide a strong >>> standard (we already have tool to make sure we never break >>> EntityReference) and it would make JS and Java sides more consistent. >>> Now In some cases we will still need to support parsing a String >>> reference in JS I think. >>> >>> On Thu, Jul 30, 2015 at 10:38 AM, vincent(a)massol.net > >>> >>> wrote: >>>> Hi Marius/all, >>>> >>>> On 30 Jul 2015 at 10:26:49, Marius Dumitru Florea ( >>> mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) >>> wrote: >>>> >>>>> +1 >>>>> Another option could be to pass a JSON serialization of the reference. >>>>> Thomas has recently fixed some issues that were preventing JSON >>>>> serialization of an entity reference. It should work fine now: >>>>> $jsontool.serialize($documentReference) >>>>> should produce something close to: >>>>> { >>>>> name: 'Page', >>>>> type: 'DOCUMENT', >>>>> parent: { >>>>> name: 'Space2', >>>>> type: 'SPACE', >>>>> parent: { >>>>> ... >>>>> } >>>>> } >>>>> } >>>>> It's more verbose obviously. For this we need to modify a bit >>>>> entityReference.js though, because it expects the entity type to be an >>>>> int. >>>> >>>> Indeed there are only 2 global solutions: >>>> * Solution 1: Pass the seralized String reference and have the js >>> perform the resolve. This also means that the java code may need to do a >>> serialize. So this has the drawback of doing a serialize + resolve. It >> has >>> the advantage of being a one-liner from JS. >>>> * Solution 2: Pass the individual elements of a reference so that the >> JS >>> doesn’t have to call resolve. This can be done in several ways: >>>> >>>> option 1: >>>> >>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>