UPDATE (December 2014) – Visualforce Remote Objects (VRO) are a better, more secure way to access Force.com from Visualforce. Use VRO rather than RemoteTK. See this blog entry for more details.
Quoting from the updated toolkit README:
The RemoteTK Visualforce Custom Component (comprising RemoteTK.component and RemoteTKController.cls) provides an abstraction very similar to the REST API, implemented via
@RemoteActionmethods in the component’s controller. The advantage of this mechanism is that no API calls are consumed.
A disadvantage is that upsert is not currently implemented.[UPDATE - Spring '13 added the ability to pass sobject type variables to Database.upsert]
Add RemoteTKController.cls and RemoteTK.component to your org by creating an Apex Class and a Component and pasting in the respective content, pasting the files into a Force.com IDE project, or by using the Force.com Migration Tool.
Since I started work on RemoteTK just last Friday it’s probably best described as ‘embryonic’, but I ported the two ForceTK sample apps to RemoteTK with just three changes (include the RemoteTK component, get an instance of the RemoteTK client, rather than ForceTK, and delete the call to setSessionToken()) and they seem to work well.
A few known issues at present:
Upsert is not supported – I haven’t figured out how to do this with a dynamic external field ID name. It might not be possible.
- describe() is a very minimal implementation – just enough to get the sample apps working.
- 0% test coverage – this prevents me from creating an unmanaged package. Much more soluble than the upsert issue!