30 Jul
2015
30 Jul
'15
10:50 a.m.
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 <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:
--
Thomas Mortagne
+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, vincent(a)massol.net 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs