On Wed, Jun 20, 2012 at 9:37 PM, Sergiu Dumitriu <[email protected]> wrote: > On 06/19/2012 11:59 PM, Caleb James DeLisle wrote: >> >> +1 >> >> Although it's never feels good implementing logic twice, converting this >> from java with gwt >> would probably introduce more problems than it solves and realistically I >> can't imagine this >> ever actually changing. >> >> It would be nicer if there was a test to compare the two or perhaps >> comments at each >> implementation warning the maintainer of the other. >> > > We should write some more Jasmine tests for JavaScript, and having the same > tests both for the Java and the JavaScript components would be a major step > towards validating the compatibility of the implementations.
In https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/src/test/javascript/spec/entityReference.js there are all the tests from https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-model/src/test/java/org/xwiki/model/internal/reference/DefaultStringEntityReferenceSerializerTest.java and testResolveDocumentReference from https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-model/src/test/java/org/xwiki/model/internal/reference/DefaultStringEntityReferenceResolverTest.java (I just didn't have the patience to port all of the resolver tests but I plan to continue it). Thanks, Marius > > >> Caleb >> >> >> >> On 06/19/2012 03:57 AM, Marius Dumitru Florea 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 > > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
