Re: [xwiki-devs] [Idea] Extensible API for accessing structured data

Interesting topic. An unified way to get data from the wiki whenever it

from client-side or server-side sounds good. I am just a bit sceptical about the selectors. The syntax your propose is simple and elegant, but it's again a new syntax to learn, and different from XWQL. I would prefer to use Document/Object/Class references, which avoid escaping problems. Something like: require(['xstore', 'xmodel'], function (Store, Model) { var tx = Store.createTransaction();

'SomeClass'), Model.createDocumentReference('', 'MySpace',

function (err, obj) { if (err) { throw err; } console.log(obj.someProperty); }); }); I agree this one might be too verbose, but that is the idea. WDYT? 2015-04-04 22:04 GMT+02:00 Caleb James DeLisle <cjd(a)cjdns.fr>fr>: > Thanks for reviewing this... > > On 04/03/2015 07:03 PM, Marius Dumitru Florea wrote: >> On Fri, Apr 3, 2015 at 6:54 PM, Caleb James DeLisle <cjd(a)cjdns.fr> > 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

> 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". > > On the one hand, I am a strong defender of namespacing, that is to say

> function > should be named in such a way that finding it's documentation is trivial > (even more > important in js where weak typing means IDEs cannot resolve function > locations). > On the other hand, I feel that a name can never truly be documentation

> easily > typed easily recognized names are superior to those which try to explain > themselves > to beginners who are not fond reading the manual... > > Your point about begin and create makes sense and according to google

> beginTransaction() and createTransaction() are used. > > So though I still have a soft spot on my heart for (begin|create)Tx(),

> ok with > createTransaction() and we can add API sugar later if it happens that > people begin > dieing from carpal tunnel syndrome or the like. > > Updated the proposal. > >> >>> >>> 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

> 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

> 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 intuitive answer is "escape all of the dots" as per our norm, IE: > Admin\.objects(XWiki\.XWikiUsers) > > Updated the proposal. > >> >> The sentence "Though this serialization scheme is prescribed, it >> should not be taken as a sign that " is missing the end. > > Updated the proposal, I meant to say: > Though this serialization scheme is prescribed, it should not be taken

> disparage the development of alternate (eg: more compact or speedier) > serialization schemes. > Because we might consider a protobuf based serialization for performance > reasons. > > Thanks, > Caleb > >> >> 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

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

> 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

> 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

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

>>>>> >>>>> 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 >>>>> >>>> >>> >>> -- >>> Satire is the escape hatch from the cycle of sorrow, hatred and > violence. #JeSuisCharlie >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > > -- > Satire is the escape hatch from the cycle of sorrow, hatred and