Opened 13 years ago

Closed 13 years ago

#8364 closed enhancement (wontfix)

Feature suggestion for JSON-based data stores -- preserve the JSON response data (except for .items)

Reported by: danilche Owned by: Jared Jurkiewicz
Priority: high Milestone: tbd
Component: Data Version: 1.2.3
Keywords: Cc:
Blocked By: Blocking:


In my code, I am using FilteringSelect? with a For performance reasons, the server-side json provider will not supply any data if the size of the data set exceeds a certain number of records (I figure it's better to not provide any data than to provide partial data, less confusing to the user). However, then, for validation purposes, I needed to be able to distinguish a query which returns empty because it gets no hits, vs. a query which returns empty because it gets too many hits -- we don't want to show the user a validation error when she simply needs to supply a narrower query.

On the server side, it's easy -- just insert an extra attribute into the JSON response, indicating that the dataset was purposefully abridged. However, there doesn't seem to be an easy way on the client side to retrieve the actual JSON response contents.

I ended up solving this by subclassing and overriding _xhrFetchHandler to store the JSON response, without the 'items' array, into a 'jsonMetaData' property on the store. Then the FilteringSelect? validation function simply checks if is true.

This seems a useful enough feature -- storing the JSON response metadata -- to make it a part of the standard datastore packages, at least the ones which use the JSON transport.

Change History (2)

comment:1 Changed 13 years ago by bill

Component: GeneralData
Owner: changed from anonymous to Jared Jurkiewicz

ISTM like the onError handler should get called and your code should check what the error was and act according.

Anyway, switching the component to Data.

comment:2 Changed 13 years ago by Jared Jurkiewicz

Resolution: wontfix
Status: newclosed

I'm not sure you're using the stores properly if you're having to do that, or your backend service isn't responding properly/honoring the concept of data paging. Instead of not returning anything, why aren't you setting a page limit for Filtering select. It has an option for it. That way you are limiting what is shown to the user (but they still have next/prev page in the select).

This doesn't sound, to me, like its a issue, but more an issue with improper usage of what already exists.

Note: See TracTickets for help on using tickets.