You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@usergrid.apache.org by Ryan Bridges <rb...@apigee.com> on 2014/03/21 14:41:57 UTC
Correcting inconsistency in the Javascript SDK
Folks,
I want to clean up the JS SDK to make it a bit more consistent. Among the
top-level objects (Entity, Collection, Group, etc), There are 2 big
inconsistencies: The validations performed before CRUD operations and the
data supplied in the callbacks from those operations. I would prefer if
the SDK performed no extra validation -- such as attempting to retrieve an
entity before updating it -- and instead performed the requested operation
and passed the error message back to be handled by the application. As for
the callbacks, some pass the response, some pass the deserialized JSON
object, and some pass the SDK object. If all callbacks were of the
form *function(err,
response, self)*, the programming model would be much easier to follow and
repeat.
Does anyone have any comments or objections?
-ryan
*ryan bridges* | *app services* | *apigee <http://apigee.com/>* | m:
+1.678.313.5334 | twitter @r <http://twitter.com/USERNAME>yanbridges
@apigee<https://twitter.com/apigee>
Re: Correcting inconsistency in the Javascript SDK
Posted by Rod Simpson <ro...@rodsimpson.com>.
I guessed as much, but still valid and can be applied to both.
Rod
--
Rod Simpson
@rockerston
rodsimpson.com
On March 21, 2014 at 12:03:52 PM, Scott Ganyo (scott@ganyo.com) wrote:
Oh! Sorry, I didn’t realize which "Javascript SDK” we were discussing. My patches are for the node SDK, not the html SDK.
Scott
On Mar 21, 2014, at 10:57 AM, Rod Simpson <ro...@rodsimpson.com> wrote:
> We should also be thinking about the Node.js module and how these same kinds of changes can be incorporated.
>
> Rod
>
>
> --
> Rod Simpson
> @rockerston
> rodsimpson.com
>
> On March 21, 2014 at 11:24:17 AM, ryan bridges (ryan@fasterness.com) wrote:
>
> Scott,
>
> If you want to send those my way, I'd be happy to incorporate them with
> what I'm doing.
>
> -ryan
>
>
> On Fri, Mar 21, 2014 at 12:16 PM, Scott Ganyo <sc...@ganyo.com> wrote:
>
>> +1 on callbacks consistency and ensuring we version correctly for
>> incompatible changes.
>>
>> Scott
>>
>> P.S. I also have some monkey patches that I’ve been using over the SDK I
>> need to submit as patches.
>>
>> On Mar 21, 2014, at 6:56 AM, Rod Simpson <ro...@rodsimpson.com> wrote:
>>
>>> +1 on the validation. We did the dupe check initially because the API
>> returned a null-pointer error when posting a dupe instead of giving you
>> back a message telling you the entity already exists.
>>>
>>> +1 on consistent callbacks. Much needed and would make the development
>> experience more predictable.
>>>
>>> We should consider incrementing the major version number since this
>> would break backwards compatibility.
>>>
>>>
>>>
>>> --
>>> Rod Simpson
>>> @rockerston
>>> rodsimpson.com
>>>
>>> On March 21, 2014 at 7:42:26 AM, Ryan Bridges (rbridges@apigee.com)
>> wrote:
>>>
>>> Folks,
>>>
>>> I want to clean up the JS SDK to make it a bit more consistent. Among the
>>> top-level objects (Entity, Collection, Group, etc), There are 2 big
>>> inconsistencies: The validations performed before CRUD operations and the
>>> data supplied in the callbacks from those operations. I would prefer if
>>> the SDK performed no extra validation -- such as attempting to retrieve
>> an
>>> entity before updating it -- and instead performed the requested
>> operation
>>> and passed the error message back to be handled by the application. As
>> for
>>> the callbacks, some pass the response, some pass the deserialized JSON
>>> object, and some pass the SDK object. If all callbacks were of the
>>> form *function(err,
>>> response, self)*, the programming model would be much easier to follow
>> and
>>> repeat.
>>>
>>> Does anyone have any comments or objections?
>>>
>>> -ryan
>>>
>>>
>>
>>
Re: Correcting inconsistency in the Javascript SDK
Posted by Scott Ganyo <sc...@ganyo.com>.
Oh! Sorry, I didn’t realize which "Javascript SDK” we were discussing. My patches are for the node SDK, not the html SDK.
Scott
On Mar 21, 2014, at 10:57 AM, Rod Simpson <ro...@rodsimpson.com> wrote:
> We should also be thinking about the Node.js module and how these same kinds of changes can be incorporated.
>
> Rod
>
>
> --
> Rod Simpson
> @rockerston
> rodsimpson.com
>
> On March 21, 2014 at 11:24:17 AM, ryan bridges (ryan@fasterness.com) wrote:
>
> Scott,
>
> If you want to send those my way, I'd be happy to incorporate them with
> what I'm doing.
>
> -ryan
>
>
> On Fri, Mar 21, 2014 at 12:16 PM, Scott Ganyo <sc...@ganyo.com> wrote:
>
>> +1 on callbacks consistency and ensuring we version correctly for
>> incompatible changes.
>>
>> Scott
>>
>> P.S. I also have some monkey patches that I’ve been using over the SDK I
>> need to submit as patches.
>>
>> On Mar 21, 2014, at 6:56 AM, Rod Simpson <ro...@rodsimpson.com> wrote:
>>
>>> +1 on the validation. We did the dupe check initially because the API
>> returned a null-pointer error when posting a dupe instead of giving you
>> back a message telling you the entity already exists.
>>>
>>> +1 on consistent callbacks. Much needed and would make the development
>> experience more predictable.
>>>
>>> We should consider incrementing the major version number since this
>> would break backwards compatibility.
>>>
>>>
>>>
>>> --
>>> Rod Simpson
>>> @rockerston
>>> rodsimpson.com
>>>
>>> On March 21, 2014 at 7:42:26 AM, Ryan Bridges (rbridges@apigee.com)
>> wrote:
>>>
>>> Folks,
>>>
>>> I want to clean up the JS SDK to make it a bit more consistent. Among the
>>> top-level objects (Entity, Collection, Group, etc), There are 2 big
>>> inconsistencies: The validations performed before CRUD operations and the
>>> data supplied in the callbacks from those operations. I would prefer if
>>> the SDK performed no extra validation -- such as attempting to retrieve
>> an
>>> entity before updating it -- and instead performed the requested
>> operation
>>> and passed the error message back to be handled by the application. As
>> for
>>> the callbacks, some pass the response, some pass the deserialized JSON
>>> object, and some pass the SDK object. If all callbacks were of the
>>> form *function(err,
>>> response, self)*, the programming model would be much easier to follow
>> and
>>> repeat.
>>>
>>> Does anyone have any comments or objections?
>>>
>>> -ryan
>>>
>>>
>>
>>
Re: Correcting inconsistency in the Javascript SDK
Posted by Rod Simpson <ro...@rodsimpson.com>.
We should also be thinking about the Node.js module and how these same kinds of changes can be incorporated.
Rod
--
Rod Simpson
@rockerston
rodsimpson.com
On March 21, 2014 at 11:24:17 AM, ryan bridges (ryan@fasterness.com) wrote:
Scott,
If you want to send those my way, I'd be happy to incorporate them with
what I'm doing.
-ryan
On Fri, Mar 21, 2014 at 12:16 PM, Scott Ganyo <sc...@ganyo.com> wrote:
> +1 on callbacks consistency and ensuring we version correctly for
> incompatible changes.
>
> Scott
>
> P.S. I also have some monkey patches that I’ve been using over the SDK I
> need to submit as patches.
>
> On Mar 21, 2014, at 6:56 AM, Rod Simpson <ro...@rodsimpson.com> wrote:
>
> > +1 on the validation. We did the dupe check initially because the API
> returned a null-pointer error when posting a dupe instead of giving you
> back a message telling you the entity already exists.
> >
> > +1 on consistent callbacks. Much needed and would make the development
> experience more predictable.
> >
> > We should consider incrementing the major version number since this
> would break backwards compatibility.
> >
> >
> >
> > --
> > Rod Simpson
> > @rockerston
> > rodsimpson.com
> >
> > On March 21, 2014 at 7:42:26 AM, Ryan Bridges (rbridges@apigee.com)
> wrote:
> >
> > Folks,
> >
> > I want to clean up the JS SDK to make it a bit more consistent. Among the
> > top-level objects (Entity, Collection, Group, etc), There are 2 big
> > inconsistencies: The validations performed before CRUD operations and the
> > data supplied in the callbacks from those operations. I would prefer if
> > the SDK performed no extra validation -- such as attempting to retrieve
> an
> > entity before updating it -- and instead performed the requested
> operation
> > and passed the error message back to be handled by the application. As
> for
> > the callbacks, some pass the response, some pass the deserialized JSON
> > object, and some pass the SDK object. If all callbacks were of the
> > form *function(err,
> > response, self)*, the programming model would be much easier to follow
> and
> > repeat.
> >
> > Does anyone have any comments or objections?
> >
> > -ryan
> >
> >
>
>
Re: Correcting inconsistency in the Javascript SDK
Posted by ryan bridges <ry...@fasterness.com>.
Scott,
If you want to send those my way, I'd be happy to incorporate them with
what I'm doing.
-ryan
On Fri, Mar 21, 2014 at 12:16 PM, Scott Ganyo <sc...@ganyo.com> wrote:
> +1 on callbacks consistency and ensuring we version correctly for
> incompatible changes.
>
> Scott
>
> P.S. I also have some monkey patches that I’ve been using over the SDK I
> need to submit as patches.
>
> On Mar 21, 2014, at 6:56 AM, Rod Simpson <ro...@rodsimpson.com> wrote:
>
> > +1 on the validation. We did the dupe check initially because the API
> returned a null-pointer error when posting a dupe instead of giving you
> back a message telling you the entity already exists.
> >
> > +1 on consistent callbacks. Much needed and would make the development
> experience more predictable.
> >
> > We should consider incrementing the major version number since this
> would break backwards compatibility.
> >
> >
> >
> > --
> > Rod Simpson
> > @rockerston
> > rodsimpson.com
> >
> > On March 21, 2014 at 7:42:26 AM, Ryan Bridges (rbridges@apigee.com)
> wrote:
> >
> > Folks,
> >
> > I want to clean up the JS SDK to make it a bit more consistent. Among the
> > top-level objects (Entity, Collection, Group, etc), There are 2 big
> > inconsistencies: The validations performed before CRUD operations and the
> > data supplied in the callbacks from those operations. I would prefer if
> > the SDK performed no extra validation -- such as attempting to retrieve
> an
> > entity before updating it -- and instead performed the requested
> operation
> > and passed the error message back to be handled by the application. As
> for
> > the callbacks, some pass the response, some pass the deserialized JSON
> > object, and some pass the SDK object. If all callbacks were of the
> > form *function(err,
> > response, self)*, the programming model would be much easier to follow
> and
> > repeat.
> >
> > Does anyone have any comments or objections?
> >
> > -ryan
> >
> >
>
>
Re: Correcting inconsistency in the Javascript SDK
Posted by Scott Ganyo <sc...@ganyo.com>.
+1 on callbacks consistency and ensuring we version correctly for incompatible changes.
Scott
P.S. I also have some monkey patches that I’ve been using over the SDK I need to submit as patches.
On Mar 21, 2014, at 6:56 AM, Rod Simpson <ro...@rodsimpson.com> wrote:
> +1 on the validation. We did the dupe check initially because the API returned a null-pointer error when posting a dupe instead of giving you back a message telling you the entity already exists.
>
> +1 on consistent callbacks. Much needed and would make the development experience more predictable.
>
> We should consider incrementing the major version number since this would break backwards compatibility.
>
>
>
> --
> Rod Simpson
> @rockerston
> rodsimpson.com
>
> On March 21, 2014 at 7:42:26 AM, Ryan Bridges (rbridges@apigee.com) wrote:
>
> Folks,
>
> I want to clean up the JS SDK to make it a bit more consistent. Among the
> top-level objects (Entity, Collection, Group, etc), There are 2 big
> inconsistencies: The validations performed before CRUD operations and the
> data supplied in the callbacks from those operations. I would prefer if
> the SDK performed no extra validation -- such as attempting to retrieve an
> entity before updating it -- and instead performed the requested operation
> and passed the error message back to be handled by the application. As for
> the callbacks, some pass the response, some pass the deserialized JSON
> object, and some pass the SDK object. If all callbacks were of the
> form *function(err,
> response, self)*, the programming model would be much easier to follow and
> repeat.
>
> Does anyone have any comments or objections?
>
> -ryan
>
>
Re: Correcting inconsistency in the Javascript SDK
Posted by Rod Simpson <ro...@rodsimpson.com>.
Forgot to add the reason for the dupe check - since the API returned a null pointer error, I had no way to know if the entity existed already or not, thus the dupe check. The null pointer error from the API has since been fixed, so the check is no longer required.
--
Rod Simpson
@rockerston
rodsimpson.com
On March 21, 2014 at 7:57:37 AM, Rod Simpson (rod@rodsimpson.com) wrote:
+1 on the validation. We did the dupe check initially because the API returned a null-pointer error when posting a dupe instead of giving you back a message telling you the entity already exists.
+1 on consistent callbacks. Much needed and would make the development experience more predictable.
We should consider incrementing the major version number since this would break backwards compatibility.
--
Rod Simpson
@rockerston
rodsimpson.com
On March 21, 2014 at 7:42:26 AM, Ryan Bridges (rbridges@apigee.com) wrote:
Folks,
I want to clean up the JS SDK to make it a bit more consistent. Among the
top-level objects (Entity, Collection, Group, etc), There are 2 big
inconsistencies: The validations performed before CRUD operations and the
data supplied in the callbacks from those operations. I would prefer if
the SDK performed no extra validation -- such as attempting to retrieve an
entity before updating it -- and instead performed the requested operation
and passed the error message back to be handled by the application. As for
the callbacks, some pass the response, some pass the deserialized JSON
object, and some pass the SDK object. If all callbacks were of the
form *function(err,
response, self)*, the programming model would be much easier to follow and
repeat.
Does anyone have any comments or objections?
-ryan
Re: Correcting inconsistency in the Javascript SDK
Posted by Rod Simpson <ro...@rodsimpson.com>.
+1 on the validation. We did the dupe check initially because the API returned a null-pointer error when posting a dupe instead of giving you back a message telling you the entity already exists.
+1 on consistent callbacks. Much needed and would make the development experience more predictable.
We should consider incrementing the major version number since this would break backwards compatibility.
--
Rod Simpson
@rockerston
rodsimpson.com
On March 21, 2014 at 7:42:26 AM, Ryan Bridges (rbridges@apigee.com) wrote:
Folks,
I want to clean up the JS SDK to make it a bit more consistent. Among the
top-level objects (Entity, Collection, Group, etc), There are 2 big
inconsistencies: The validations performed before CRUD operations and the
data supplied in the callbacks from those operations. I would prefer if
the SDK performed no extra validation -- such as attempting to retrieve an
entity before updating it -- and instead performed the requested operation
and passed the error message back to be handled by the application. As for
the callbacks, some pass the response, some pass the deserialized JSON
object, and some pass the SDK object. If all callbacks were of the
form *function(err,
response, self)*, the programming model would be much easier to follow and
repeat.
Does anyone have any comments or objections?
-ryan