3 Apr
2015
3 Apr
'15
5:54 p.m.
Well I made a "few small changes" (which expanded into eventually a total
rewrite).
Fundamentally I really wanted to have access to transactional storage, even if it
is not truly transactional at the storage level, exposing a transaction based API
will make adding the transactions much more powerful in the long run.
Furthermore I opted to remove promises because there is currently a small standards
war over which promises will be used and my experience from the js world is that
when the best choice is not blatantly clear, it means the clear choice has not been
invented (quite) yet.
Third, and likely most controversial, I wanted to have a single concept of getting
a document or object by identifier or by query so I a bit unilaterally invented this
concept of a "selector", which is backward compatible with names as defined in
getDocument, respectful of the document.objects(Class.Name) method of selecting
objects in XWQL and capable of expanding fluidly to xwql or any other query language
which we might add later on. I chose the :: notation as a separator but it's not set
in stone so I'd be happy to hear well reasoned justification for changing it.
Lets start a conversation.
Caleb
On 03/17/2015 06:11 PM, Caleb James DeLisle wrote:
I have been meaning to review this API, I finally got
a chance to do so
and I have some suggestions for changes to it. Of course I don't want to
take away from the spirit of the idea too much but I have a few suggestions
which reflect things which I often find myself wanting to do in my applications.
I've updated the page adding things which came to mind as I reviewed the proposal.
One major thing I would like to see is transactions, I know it makes the api
more cumbersome but it does not need to make it much more cumbersome, it gives
the programmer much more power if they want it and and it can potentially improve
performance in the javascript version as it can flush all of it's changes back at
once, rather than making many http requests.
A second comment is on the semantics of the store and get requests, I would like
to see common semantics between the get/set of object fields in velocity/groovy
and in Javascript, using a JSON Map to specify groups of fields to set is suboptimal
because I would like them to be checked as they are set.
Clearly velocity and groovy XObjects can have general purpose get()/set() methods
which throw errors if invalid values are passed and after some research, I determined
that in Javascript, the Object.preventExtensions() and Object.defineProperty()
can be used to prevent the user setting any non-existant variables but can also
type-check the variables as they are set.
Overall I'm fairly excited with this proposal and it will be interesting to see
how it turns out.
Thanks,
Caleb
On 02/27/2015 10:48 AM, Fabio Mancinelli wrote:
--
Satire is the escape hatch from the cycle of sorrow, hatred and violence. #JeSuisCharlie
Hi all,
some time ago we wrote about an idea of having an extensible API for
accessing structured data.
The final goal is to have a uniform API for accessing structured data
both on the client (Javascript+REST) and on the server.
We have written a little design document that I am submitting to the
list for comments:
http://design.xwiki.org/xwiki/bin/view/Proposal/ExtensibleAPIforaccessingst…
This idea is also related to other ones, like providing a way for
dynamically extending the REST API, and also to the integration with
client side frameworks like AngularJS.
Thanks,
Fabio
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs