Server side stores in nodejs (to be used in Dojo)

I am writing this great application. It's my first attempt to write a one page fully AJAX application that only uses Restful stores on the other side.

Now... I wrote some of the code, and up to this point I have only needed simple queries with GET. However, in order to keep everything neat, I made sure that I had a "protocol" into place: each request had a response in the format:

{↵ "ack": "ERROR", "message": "required filter not passed",↵ "errors": { "name": "parameter required"↵ } }

In case there are errors (in this case, I require users to set a filter).

Now... if the GET does work, I also have a "data" field so that the result looks like this:

{↵ "ack": "OK", "data": { ... } }

Now I am having problems with Dojo, because for example dgrid expects data in the "root" (so to speak) of the returned object, rather than the "data" key.

Possible solutions:

1) Hack my JsonRest file (it's already a little different, I added timeouts etc, it IS meant to be a boilerplate after all) so that, for "queries", it actually manipulates results with a then() and returns raw data

2) Change my protocol, so that if the HTTP status is 200, and since there is no error message or anything to give out, it simply returns the data

3) Convince somehow all the widgets to use stuff in the "data" part of the returned JSON after a query (this seems highly unlikely).

Which way should I go? On one hand, I like the fact that the protocol follows the same format all the time (although I admit it's useless). On the other hand, changing JsonRest seems easy enough. But then AGAIN, third party APIs might not like having to fish out data from the "data" key of the returned object...

What's the sane thing to do here?

Thanks!

Merc.

I haven't tried this but the docs indicate that if the JsonRest query generates an HTTP error code, the xhr error object will get passed all the way up to the dgrid and is one of the data associated with the dgrid-error event.

dgrid core components
dgrid issue mentioning query errors

If that works correctly then I would go with solution 2 because it requires the least modifications to standard components and uses only the API provided.