Hi,
I concur, I think a key improvement would be to have access to all
document information when accessing a document resource ; including
objects, objects properties, tags, etc.
This could be implemented with a resource expansion like
"/rest/[...]/documents/Foo?expand=objects,tags" but could be as well be
the default behavior, there is no extra cost since the document is fully
"loaded" when accessed.
Jerome
On 04/16/2013 07:25 PM, Ludovic Dubost wrote:
Hi,
I've been experimenting with AngularJS and XWiki and I find the two
technologies are a pretty good fit.
You can see a demo of some AngularJS taking to an XWiki backend:
The extension is here:
http://extensions.xwiki.org/xwiki/bin/view/Extension/AngularJSDemo
A demo is here:
http://www.ludovic.org/xwiki/bin/view/Phones/AngularSearch
What I like a lot about AngularJS is the template approach while still
being able to bind dynamic behavior and the fact that there is no backend
compile making it a great fit for integration in XWiki pages.
The demo is a angularJS screen right in an XWiki page. The controler could
have been written as a JS Extension but in the demo it is also in the same
page. The controler is calling both LiveTable JSON pages and REST pages to
retrieve individual documents.
XWiki's current REST apis are far from optimal to quickly retrieve the
needed information to display as I had to configure 3 requests to get the
page information, the main object and the attachment list. However with
AngularJS this was very transparent as you did not need to chain the
requests. Now if would be better if we improved our REST apis with that
type of framework in mind. I've long thought that our REST system lacks the
flexibility we have with XWiki pages. If we want to have the same
flexibility with AJAX development and use and improve our REST apis instead
of writing additional APIs in XWiki pages, then we need an easy way to
extend or override existing REST apis. This could be achieved using Groovy
Scripts that the REST api can dynamically load. These groovy script your
replace, add or extend existing APIs. The example of the LiveTable is a
very good example of the lack of flexibility/speed the development of
additional REST apis represent. If we had had that flexibility the
livetable backend code could be written as REST apis and not as an XWiki
page. This is something we need to fix in our development model if we want
to be a good Javascript UI citizen.
We could push this type of integration way further providing an XWiki
service for AngularJS which would simplify reading XWiki data and
transforming it to the right objects for using in AngularJS templates. We
could also provide additional filters and features for editing.
In any case I believe this is something we really need to look into more in
the future as the embedding works quite well and the angular JS development
model fits the XWiki one quite well. It has the same "visual" aspect as
velocity development but in Javascript with the additional dynamicity.
WDYT ?
Ludovic