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/cfa8ec3315a32fed875949ff21a5d....
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/cfa8ec3315a32fed875949ff21a5d... 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/cfa8ec3315a32fed875949ff21a5d... with unit tests in https://github.com/xwiki/xwiki-platform/commit/cfa8ec3315a32fed875949ff21a5d... . 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