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
