Opened 15 years ago

Closed 15 years ago

#3342 closed enhancement (duplicate)

Impliment a data provider with JSON server side filtering support.

Reported by: guest Owned by: Jared Jurkiewicz
Priority: high Milestone: 1.1
Component: Data Version: 0.9
Keywords: Cc:
Blocked By: Blocking:


JsonDataProvider? without server side support is not useful when the number of items you are filter starts to grow past 15k or so (as in the case of my million+ records). Please add some server-side filtering support in a default provider.

Sure I could implement one myself, but a generic would be easier.

Change History (10)

comment:1 Changed 15 years ago by skinner

Cc: [email protected] added
Owner: changed from skinner to anonymous

A general-purpose datastore with server-side filtering sounds like a good idea to me. It's not something I've got time to work on, but if you get one working please do consider contributing it to dojo. ~skinner

comment:2 Changed 15 years ago by Adam Peller

Cc: [email protected] removed
Owner: changed from anonymous to Jared Jurkiewicz

What should we do with this ticket?

comment:3 Changed 15 years ago by Jared Jurkiewicz

I'm not sure. I don't see the point of providing a frontend service that calls a backend service without providing the backend service too. Otherwise we have no way to effectively test it. I don't really see how it would be 'generic'. When you go to backend services, the Client Datastore is bound to the service interface contract, which in general, varies immensely from point to point.

A very basic Read datastore than shims over a service that does all the filtering and sorting support, quite frankly, is a very trivial store to implement in general (Look at FlickrStore? in dojox, for example. It filters flickr tags serverside). The heavy lifting would all be in generating the service specific query and parsing the service specific results.

The whole *idea* of is a generic data interface users can write to, to meet the needs of their service interface and QoS.

comment:4 Changed 15 years ago by bill

Milestone: 1.0

For me I'd like to have a proof of concept PHP file as the server, checked in somewhere (to a test directory). Doesn't have to do caching etc. We need something like this to test FilteringSelect? anyway.

comment:5 Changed 15 years ago by Jared Jurkiewicz

People are always welcome to write and contribute one. I'd *really* appreciate getting more community involvement with implementing datastores. This isn't the Jared project, it's supposed to be a community development effort. so far I've been the one doing all the primary development on it for the past several months, as well as all the docs, running the meetings, doing minutes, etc. I would *really* appreciate others in the community stepping up and contributing too.

comment:6 Changed 15 years ago by guest

As fas as I understand, jaredj wasn't interested to invest time into these things. But in the meantime, there is a new Datastore on the way ( Let us support this guy as much as possible!

comment:7 Changed 15 years ago by Jared Jurkiewicz

Milestone: 1.01.1

It doesn't have to do with interest, it has to do with available time, of which I have very little right now. I don't appreciate that comment given how much work I have put into I stated I couldn't do it all and would appreciate community help.

comment:8 Changed 15 years ago by alex

jared: you're totally justified in punting this to 1.1. Ignore the trolls.

comment:9 Changed 15 years ago by bill

This looks like a dup of #4597 to me. Now that that code is checked in you can just close this, right? Or is there something else people want besides what's in QueryReadStore??

comment:10 Changed 15 years ago by bill

Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.