9 Apr
2015
9 Apr
'15
5:14 p.m.
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.
Also do you have a proposal for running searches if we used references
instead of selectors?
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 <cjd(a)cjdns.fr>fr>:
--
Satire is the escape hatch from the cycle of sorrow, hatred and violence. #JeSuisCharlie
Thanks for reviewing this...
On 04/03/2015 07:03 PM, Marius Dumitru Florea wrote:
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.
--
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
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 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 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/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
>>>
>>
>
> --
> 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