On Fri, Apr 3, 2015 at 6:54 PM, Caleb James DeLisle <[email protected]> wrote: > 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.
I'm not fond of cryptic names like beginTx (I know you prefer shorter names). Moreover seeing "beginXXX" made me look for "endXXX". Maybe a better name is "createTransaction". > > 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. How will you handle pagination in getItems()? How will you escape special characters in the selector? Considering that I can create a document named "Admin.objects(XWiki.XWikiUsers)". The sentence "Though this serialization scheme is prescribed, it should not be taken as a sign that " is missing the end. Thanks, Marius > > 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: >>> 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/ExtensibleAPIforaccessingstructuredata >>> >>> 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 >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> > > -- > Satire is the escape hatch from the cycle of sorrow, hatred and violence. > #JeSuisCharlie > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
