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.
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
