2015-04-09 17:14 GMT+02:00 Caleb James DeLisle <[email protected]>:
> I'm not sure I agree that the syntax is significantly different from XWQL
> and it's important to me that developers who are used to
> $xwiki.getDocument("Main.WebHome") will have a clear path to the new API,
> and in the case of selectors they don't need to know the syntax for most
> purposes.
>
> I recognize the value of references for issues where escaping might be
> needed, for example: $xwiki.getDocument("${userDefinedSpace}.WebHome")
> is a possible escaping issue, however in order to roll out references in
> the first development, I think we need to verify that there is enough
> demand for this design pattern to warrant hardening it.
>
It could be a reference serializer that generates the appropriate selector.
>
> Also do you have a proposal for running searches if we used references
> instead of selectors?
>
No, selectors are good for that purpose.
>
>
> Thanks,
> Caleb
>
>
> On 04/09/2015 04:08 PM, Guillaume "Louis-Marie" Delhumeau wrote:
> > 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
> >>
> >
> >
> >
>
> --
> 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
