Hi, It's good to have those APIs client side as well.
Concerning the location, it doesn't not belong in resources/uicomponents/model/entityReference.js (it's not an UI component) ; maybe in resources/model/entityReference.js ? Jerome On Tue, Jun 19, 2012 at 9:57 AM, Marius Dumitru Florea <[email protected]> wrote: > > On Tue, Jun 19, 2012 at 10:42 AM, Thomas Mortagne > <[email protected]> wrote: > > On Tue, Jun 19, 2012 at 9:37 AM, Thomas Mortagne > > <[email protected]> wrote: > >> On Tue, Jun 19, 2012 at 8:38 AM, Thomas Mortagne > >> <[email protected]> wrote: > >>> On Mon, Jun 18, 2012 at 8:57 PM, Marius Dumitru Florea > >>> <[email protected]> wrote: > >>>> Hi devs, > >>>> > >>>> While fixing http://jira.xwiki.org/browse/XWIKI-7889 I introduced an > >>>> API to resolve and serialize entity references on the client side > >>>> (JavaScript code). See > >>>> https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5dcaa9d2c7f35. > >>>> > >>>> XWiki Explorer tree has an input displayed at the bottom where you can > >>>> type a _pseudo_ entity reference which is parsed and the specified > >>>> entity is selected in the tree. The basic problem (very simplified) > >>>> was that this reference was parsed on the client side and the parsing > >>>> code did not handle special characters in entity name (no escaping). > >>>> Of course, I had to options: > >>>> > >>>> * add a service (REST?) to resolve/serialize the reference on the server > >>>> or > >>>> * (as I did) port part of the code from xwiki-platform-model (with > >>>> unit tests!) to JavaScript to be able to resolve/serialize entity > >>>> references on the client side. > >>>> > >>>> There are pros and cons for each option but for me the main reason was > >>>> that it is painful to modify xwikiexplorer.js to make AJAX requests > >>>> each time you type into that input box (the tree node is selected as > >>>> you type). An almost complete rewrite was needed and since we're > >>>> looking to replace that tree I thought the second option was better. > >>>> > >>>> Would be great if you can review my commit. I'm interested in the API > >>>> naming and places where I put the JS code. Also, I'm not sure where to > >>>> document the new API (that is if no one is against it). > >>> > >>> Counting on Ajax call each time you need to parse/serialize a > >>> reference sounds pretty bad for performances anyway so better having a > >>> client side implementation. I agree with Vincent that it's going to be > >>> some work to maintain it but I don't see much choice. > >>> > >>> What I see in > >>> https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5dcaa9d2c7f35 > >>> is very different from the Java modele API, If we go for having a JS > >>> version of the reference API I think I would prefer to start something > >>> a lot more in sync (even if partial) grouped with the Java modele > >>> module under the same parent or something on git/maven so that it's > >>> clear that they are supposed to be in sync as much as possible. Not > >>> sure how we can package the JS lib, zip ? It's a lot easier to keep in > >>> synch two things that look like each other. > >> > > >> Sorry was not looking at the right new methods. Still I think it would > >> be nice to put the Java and JS versions under the same parent if > >> possible. > > The actual API is > https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5dcaa9d2c7f35#diff-3 > with unit tests in > https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5dcaa9d2c7f35#diff-5 > . > > I'm fine with moving under the same parent, but I'm not sure how. I > see that skins generate a zip which is then unpacked and integrated in > the war. We could probably do the same. > > > This API does not seems to have the concept of different kind of > > resolver/serializer (current, compact, etc.). Is there something I did > > not seen ? > > It doesn't. We don't have a component manager on the client side so it > was easier/quicker for me write a simple resolver/serializer (based on > the Abstract/Default entity reference resolver/serializer from > xwiki-platform-model) which parses/serializes only what it gets. The > rest can be added on top of this: > > * after you resolve a string entity reference, in your code you can > add the missing entity reference parts or replace the empty ones. We > can write something generic but I didn't need it so far > * in order to serialize relative to another entity reference I added > XWiki.EntityReference#relativeTo which removes common entity reference > parts > > Thanks, > Marius > > > > >> > >>> > >>>> > >>>> Thanks, > >>>> Marius > >>>> _______________________________________________ > >>>> devs mailing list > >>>> [email protected] > >>>> http://lists.xwiki.org/mailman/listinfo/devs > >>> > >>> > >>> > >>> -- > >>> Thomas Mortagne > >> > >> > >> > >> -- > >> Thomas Mortagne > > > > > > > > -- > > 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 -- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
