Re: [xwiki-devs] [Proposal] Best practice: use References in JS code
On 27 Aug 2015 at 10:34:17, Caleb James DeLisle ([email protected](mailto:[email protected])) wrote:
Ahh ok, +1 to explosing the absolute cannonical reference, however I will point out that use of "this" in javascript is dangerous and should be avoided. It looks like you're attaching it to the global namespace (aka window) but "this" has different meanings depending on where you are in the code. Better XWiki.doc.reference or similar IMO.
I was referring to modifying this existing code: XWiki.Document = Class.create({ /** * Constructor. All parameters are optional, and default to the current document location. */ initialize : function(page, space, wiki) { this.page = page || XWiki.Document.currentPage; this.space = space || XWiki.Document.currentSpace; this.wiki = wiki || XWiki.Document.currentWiki; }, so that instead (or rather in addition to not break backward compat), we can also pass a full reference. Thanks -Vincent
Thanks, Caleb
On 27/08/15 10:23, [email protected] wrote:
On 26 Aug 2015 at 18:23:42, Caleb James DeLisle ([email protected](mailto:[email protected])) wrote:
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 ?
This is indeed my original proposal in the first mail:
“[…]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); “
Thanks -Vincent
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 < [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] > >>> 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: > >
> wiki
> page
>
> space1
> space2
>
>
> > option 2: > > The JSON you suggest above. However, how would the java code pass this into HTML? Inside a tag’s text, as in: > >
> … json here?... >
> > Inside a
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I see, +1 On 27/08/15 11:13, [email protected] wrote:
On 27 Aug 2015 at 10:34:17, Caleb James DeLisle ([email protected](mailto:[email protected])) wrote:
Ahh ok, +1 to explosing the absolute cannonical reference, however I will point out that use of "this" in javascript is dangerous and should be avoided. It looks like you're attaching it to the global namespace (aka window) but "this" has different meanings depending on where you are in the code. Better XWiki.doc.reference or similar IMO.
I was referring to modifying this existing code:
XWiki.Document = Class.create({ /** * Constructor. All parameters are optional, and default to the current document location. */ initialize : function(page, space, wiki) { this.page = page || XWiki.Document.currentPage; this.space = space || XWiki.Document.currentSpace; this.wiki = wiki || XWiki.Document.currentWiki; },
so that instead (or rather in addition to not break backward compat), we can also pass a full reference.
Thanks -Vincent
Thanks, Caleb
On 27/08/15 10:23, [email protected] wrote:
On 26 Aug 2015 at 18:23:42, Caleb James DeLisle ([email protected](mailto:[email protected])) wrote:
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 ?
This is indeed my original proposal in the first mail:
“[…]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); “
Thanks -Vincent
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 < [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] > >>> > 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: >> >>
>> wiki
>> page
>>
>> space1
>> space2
>>
>>
>> >> option 2: >> >> The JSON you suggest above. However, how would the java code pass this > into HTML? Inside a tag’s text, as in: >> >>
>> … json here?... >>
>> >> Inside a
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
Caleb James DeLisle -
vincent＠massol.net