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 <[email protected]>: > 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 < > [email protected] > > 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, [email protected] <[email protected] > > > > wrote: > > > Hi Marius/all, > > > > > > On 30 Jul 2015 at 10:26:49, Marius Dumitru Florea ( > > [email protected](mailto:[email protected])) > > 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: > > > > > > <div class=“metadata”> > > > <div class=“sourcewiki”>wiki</div> > > > <div class=“sourcepage”>page</div> > > > <div class=“sourcespaces”> > > > <div>space1</div> > > > <div>space2</div> > > > </div> > > > </div> > > > > > > option 2: > > > > > > The JSON you suggest above. However, how would the java code pass this > > into HTML? Inside a tag’s text, as in: > > > > > > <div class=“metadata”> > > > … json here?... > > > </div> > > > > > > Inside a <script> tag directly? > > > > > > Note that option2 has a big advantage over option 1: JS knows JSON > > natively and thus there’s no need to implement any parsing at the JS > level. > > > > > > Compared to Solution 1, the advantage would to avoid a resolve() call > on > > the JS side. On the java side we’ll still need the serialize() call > (which > > will possibly take slightly longer than the string serialization). > > > > > > Overall Solution 2/option2 could be a better solution indeed. > > > > > > What do others think? > > > > > > Thanks > > > -Vincent > > > > > >> Thanks, > > >> Marius > > >> > > >> On Wed, Jul 29, 2015 at 4:34 PM, [email protected] wrote: > > >> > Hi devs, > > >> > > > >> > In the past we use to pass the wiki, space and page as 3 variables > to > > JS code. For example in dashboard.js we currently have: > > >> > > > >> > this.sourcePage = this.element.down('.metadata > > .sourcepage').innerHTML; > > >> > this.sourceSpace = this.element.down('.metadata > > .sourcespace').innerHTML; > > >> > this.sourceWiki = this.element.down('.metadata > > .sourcewiki').innerHTML; > > >> > > > >> > Now that we need to handle Nested Spaces, it’s more complex and I’m > > proposing to change our best practice and instead to pass a full > reference, > > as in: > > >> > > > >> > this.sourceReference = > > XWiki.Model.resolve(this.element.down('.metadata .source').innerHTML, > > XWiki.EntityType.DOCUMENT); > > >> > > > >> > More generally the idea would be to do the same as we do in Java > > code, i.e. to start stopping passing several parameters to functions and > > instead to use XWiki.EntityReference (or XWiki.DocumentReference, etc). > > >> > > > >> > For example for dashboard.js this allows to replace: > > >> > > > >> > var link = new Element('a', {'href' : this.sourceURL}); > > >> > link.update(this.sourceWiki + ':' + this.sourceSpace + '.' + > > this.sourcePage); > > >> > > > >> > With: > > >> > > > >> > var link = new Element('a', {'href' : this.sourceURL}); > > >> > link.update(XWiki.Model.serialize(this.sourceReference)); > > >> > > > >> > WDYT? > > >> > > > >> > Thanks > > >> > -Vincent > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > -- > > Thomas Mortagne > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
