What version are you using? In the latest SVN version it seems to work as you would expect (creating a URL like /rest.php?foo=1). It is possible that this was a bug in a previous released version.

This is still reproduceable using the latest from svn. Although it is very possible that I'm using it wrong.

So, lets say i have a RPC class defined as:

pyrite.rpc.program = new dojox.rpc.Service({
transport:'REST',
envelope: "URL",
contentType:"application/json",
services: {
restService: {
target: 'rest/Program',
transport: 'REST',
contentType:"application/json",
parameters: [
{name: "id", type: "int", optional: true}
]}
}
});

And then a dojox.store defined as:
pyrite.store.program = new dojox.data.JsonRestStore({service:pyrite.rpc.program.restService, idAttribute:'program_id', labelAttribute:'name'});

When i do something like pyrite.store.program.fetch({query:{name:'test'}}); as would be generated from, say, a filteringSelect, the URL that comes out is the ?query=%5B Object ... %5B one. However, I've found that if i change the transport from REST to GET this resolves the problem, so its something to do with the REST implementation.

To make my life easier I've changed the way I'm defining stores to use the target parameter:
pyrite.store.program = new dojox.data.JsonRestStore({target:pyrite.config.rest + '/Program', idAttribute:'program_id', labelAttribute:'name'});

Which gets around the weird url problems.

However, I'm still having problems saving stuff.
pyrite.store.program.fetch({query:{id:1}, onItem:function(i){p=i}});
pyrite.store.program.changing(i);

Doesn't seem to do anything, as pyrite.store.program.isItem(p) and pyrite.store.program.isDirty() both return nothing. Which makes me think that the data I'm returning isn't quite proper: Right now I'm just returning an array of items:
[{'program_id':1, 'name':'test'},{'program_id':2, 'name':'test #2'}]

Furthermore There are some issues when hooking up a JSON store to a filtering select:
If i have something like:
pyrite.store.program = new dojox.data.JsonRestStore({target:pyrite.config.rest + '/Program', idAttribute:'program_id', labelAttribute:'name'});

I can dropdown stuff from the filteringselect, but when i click on one I get the error: 'Error: Identity attribute not found' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "" data: no]
Which makes me think that the idAttribute:'program_id' isnt actually doing anything

Finally, If i hook up a servicestore to a filtering select there is a bug when the value of the filering select is already defined.
So, for example if i have a service store defined as:
pyrite.store.area = new dojox.data.ServiceStore({service:
new dojox.rpc.Service({
transport: "POST",
envelope: "URL",
strictParameters: false,
parameters: {
appId: {},
outputType: {
"default": "json"
},

ignoreErrors: {
optional: true
}
},
services: {
jsonRestStore: {
transport: "GET",
target: pyrite.config.rest + '/Area',
contentType:"application/json",
parameters: [
{name: "id", type: "int", optional: true}
]
},
}
}).jsonRestStore,
idAttribute:'area_id',
labelAttribute:'name'
});

And a filtering select defined as:

The Filtering select is not populated with the name of the area, as it is with the dojo.store.ItemFileReadStore, so there is something funny going on with the lookup: Perhaps its calling pyrite.store.area.fetchItemByIdentity() before there are items cached in pyrite.store.area

I totally understand that the dojox.data and dojox.rpc are a work in progress and me pointing out all the problems I'm having (some of which are certainly due to my own ignorance and misuse of the Classes) may not be that helpful, but I hope it helps to squash some bugs.

I can't wait until the realease of 1.2 when all this stuff is ready for use!

Dustin,
My apologies for being slow to respond, thank you for the samples, I was able to track down the bugs in the Rest service and JsonRestStore with your examples. The malformed URLs created from the Rest service and the isDirty function should be fixed now (in SVN).

With your example:
pyrite.store.program.fetch({query:{id:1}, onItem:function(i){p=i}});
pyrite.store.program.changing(i);
This may not be working because the second line is executed before the fetch is finished (it is done asynchronously). The following code seemed to work properly with your example code (once the bug was fixed):
store.fetch({query:{id:1}, onItem:function(i){
console.log("isItem",store.isItem(i));
console.log("isDirty",store.isDirty(i));
store.changing(i);
console.log("isDirty",store.isDirty(i));
}});
Returning:
isItem true
isDirty false
isDirty true

As far as FilteringSelect, once these bugs were fixed I couldn't find any problems using JsonRestStore or ServiceStore with the FilteringSelect. Let me know if you still have any issues.

Hey kzyp,

Thanks for all your hard work!! The store does seem to be working properly now. For the .changing() thing, I dont think it was an async problem as i was issuing commands in Firebug and waiting for them to complete. I think the store wasnt writing out the __id parameter to the object, but, as you said its working perfectly now.

With regards to the filtering select: With the JsonRestStore it works just fine I found :). However, it is the ServiceStore that has problems (not sure if you are involved in this one). I am assuming that the FilteringSelect calls .fetchItemsByIdentity on the store. In the case of the serviceStore, if it does not have an item with that Id cached it simply returns undefined, rather than trying to do a synchronous fetch from the server.

Thoughts?

Thanks!!
Dustin

Dustin,
I have made some changes so the fetchItemByIdentity behavior should be the same between ServiceStore and JsonRestStore (they just use a different index). Hopefully that will fix the problem you are seeing with ServiceStore, let me know if it doesn't