Interesting topic. An unified way to get data from the wiki whenever it is
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();
tx.getItem(Model.createObjectReference(Model.createClassReference('AnotherSpace',
'SomeClass'), Model.createDocumentReference('', 'MySpace', 'MyDocument')),
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 <[email protected]>:
> 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 <[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".
>
> On the one hand, I am a strong defender of namespacing, that is to say any
> 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 so
> 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 both
> beginTransaction() and createTransaction() are used.
>
> So though I still have a soft spot on my heart for (begin|create)Tx(), I'm
> 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 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 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 to
> 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 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
> >
>
> --
> 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
>
--
Guillaume Delhumeau ([email protected])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
