The Apex Developer’s Guide has a section Best Practices for Using Remote Objects that is very well written and, generally, addresses what Remote Objects are good for and what they aren’t. Here is the first sentence on the page:
Visualforce Remote Objects is an effective tool for quickly adding simple data operations to Visualforce pages.
The page then goes on to cover limitations with transaction boundaries (e.g., inserting an Order and Order Products in one transaction isn’t possible), addresses issues on business logic placement, handling complexity, and gives alternatives to Remote Objects.
The short answer is simple CRUD based functionality is where Remote Objects work best. For example, an app that lets you edit Contact information, or an app that displays a List of some Object, etc., are good. A complex financial system, probably not a good fit.
Know that there are documented limitations. It is still in developer preview so is subject to change without backward compatibility and it is also documented as not yet feature complete.
Can it be used in PE?
I didn’t see it documented anywhere that they can’t be used in a PE org. I just signed up for a Professional Edition Pre-release on the pre-release sign up page and was able to use Remote Objects without issue.
OPTION 1: Nested logical constructions to prevent the clash of identifiers
where: {
or: {
BillingState: { eq: 'Hawaii' },
or: {
BillingState: { eq: 'Alaska' },
or: {...},
},
},
Name: { like: '% Assoc%' }
}
Caution: it seems to be important, that all ors and ands have at least two nodes. So if necessary, you have to add fake-conditions which evaluate neutrally to your needs.
OPTION 2: Add the Model fields twice (not verified)
<apex:remoteObjects jsNamespace="RemoteObjectModel">
<apex:remoteObjectModel name="Account" >
<apex:remoteObjectField name="BillingState" jsShorthand="State1"/>
<apex:remoteObjectField name="BillingState" jsShorthand="State2"/>
</apex:remoteObjectModel>
</apex:remoteObjects>
Best Answer
Yes.