All data transmitted with JavaScript Remoting is JSON. You need never encode nor decode it. Eg:
public List<Contact> findContactsForAccount(Id accountId, String lastName) {
return [
SELECT Id
FROM Contact
WHERE AccountId = :accountId AND LastName LIKE :('%' + filter + '%')
];
}
What goes up the wire is an array of the method arguments: (accountId, lastName)
['00100000000000A999', 'smith'] //some account id and last name
What comes down the wire is the return type of the remote method, eg: (List<Contact>)
[{Id: '003000000000001AAA'}, {Id: '003000000000002AAB'}] //contacts
This is all taken care of by the platform's remoting client and service.
Your Sencha proxy will expect certain signatures, however:
For example, a proxy for a GridPanel's flat store:
@RemoteAction List<Model__c> create(List<Model__c> models);
@RemoteAction List<Model__c> read(String filter);
@RemoteAction List<Model__c> modify(List<Model__c> models);
@RemoteAction void destroy(List<Model__c> models);
Or a proxy for a TreePanel's hierarchical store:
@RemoteAction List<Node__c> create(List<Node__c> nodes);
@RemoteAction List<Node__c> read(Id parentId);
@RemoteAction List<Node__c> modify(List<Node__c> nodes);
@RemoteAction void destroy(List<Node__c> nodes);
If you want the proxy to take care of the comms for you, it's up to you to offer it the services in this format. For example on your proxy's reader, you'll want to set allowSingle to false so that your service signatures are always collections (even if that's almost always a collection-of-one).
If you want to send/receive data that doesn't really fit into CRUD operations yet take advantage of the proxy, you might wrap your Request and Response up into stores whose fields hold the arguments of the commands you want to send:
An example service that isn't very CRUD:
public Map<Id,Boolean> sendEmailToAllThesePeople(List<Contact> contacts) {
Map<Id,Boolean> statuses = new Map<Id,Boolean>();
for (Contact contact : contacts) {
if (...) {
//ok to email this contact
statuses.put(contact.Id, true);
} else {
//maybe this contact opted out
statuses.put(contact.Id, false);
}
}
return statuses;
}
You can 'massage' the client around it to fit:
Ext.define('My.store.EmailAttempt', {
extend: 'Ext.data.Store',
id: 'EmailAttempt',
proxy: {
type: 'vfremote',
api: {insert: $RemoteAction.MyController.sendEmailToAllThesePeople}
reader: {
type: 'json',
getData: function(statuses) {
var rows = [];
for (var i in statuses) {
//convert the 'map' into actual 'records'
rows.push({Id: i, Status: statuses[i]});
}
return rows;
}
}
},
fields: [
{name: 'Id', type: 'string'},
{name: 'Status', type: 'boolean'}
]
});
You get all the benefits of error handling, data binding, templating etc, your Ext application can deal in terms of models and stores, and you can invoke Ext.getStore('EmailAttempt').add(contact) in your client-side Ext controller or as appropriate.
The goal here is to configure the Sencha application into shape so that it forms the JSON expected by your services and you never see any of that going on at the transport layer.
