[SalesForce] Difference between @RemoteAction annotation and
Can someone tell me the difference between these VF tags… in brief?
Best Answer
@RemoteAction and apex:actionFunction are essentially polar opposites in terms of functionality, even though they both offer JavaScript functionality.
@RemoteAction methods are static, and therefore can't see the current page state directly, while apex:actionFunction methods are instance methods, and so can see the entire page state.
@RemoteAction methods require less bandwidth, and server processing time, because only the data you submit is visible and the view state is not transferred, while apex:actionFunction has to transfer the page view state.
@RemoteAction methods have to update the DOM manually using explicit JavaScript, while apex:actionFunction methods automatically update the Visualforce DOM and can refresh part or all of the page, and can provide a standard interface for showing a loading status through apex:actionStatus.
@RemoteAction methods can return data directly back to the calling JavaScript, but cannot update the page's view state. apex:actionFunction methods can update the page's view state and DOM structure, but cannot return data directly back to JavaScript (although you can do this with some extra effort using oncomplete).
Because of these polar differences, there is almost always "one right answer" for which method should be used in a given situation. An auto-complete-as-you-type feature would benefit from @RemoteAction, because less data is used, and so it is faster and more responsive; we don't need to modify the view state, so this is a major bonus for the user. Updating the page's view state to show new Visualforce elements, in contrast, would best be served with apex:actionFunction; using a @RemoteAction would force the developer to manage the DOM themselves, which can be more burdensome.
Also, you generally can't modify the DOM in native JavaScript if you use apex:actionFunction, because those changes won't appear in the view state and will be overwritten if the DOM node the changes appeared in is refreshed. This means that JavaScript designed to use @RemoteAction and update the DOM as a result will generally be incompatible with apex:actionFunction. There's exceptions to this rule, of course, as long as both uses are isolated from each other or interact only in a carefully designed order of operations.
If you're looking for the value of a single variable, then it would make sense that the operator would be "equal" to the value of the specified variable, it wouldn't be "IN" the variable as if your query has to sort among a group of records.
According to syntax, if your variable is a list or set, you'd expect the value to be "IN" the list or set, not "equal" to the value of the list or set. Often times it makes no difference which one you use for a list or set as Apex is smart enough to understand what you intended. It could also be a question of did you want all the values contained in the list or set, or only some of them that makes the difference on which to use that clarifies the intent, but generally if a list or set, using "IN" would be the proper syntax.
Where it's essential to use "IN" is when you use a map. A value of an operator can't be "equal" to a map can it? Instead, it has to be contained "IN" the map.
Best Answer
@RemoteActionandapex:actionFunctionare essentially polar opposites in terms of functionality, even though they both offer JavaScript functionality.@RemoteActionmethods are static, and therefore can't see the current page state directly, whileapex:actionFunctionmethods are instance methods, and so can see the entire page state.@RemoteActionmethods require less bandwidth, and server processing time, because only the data you submit is visible and the view state is not transferred, whileapex:actionFunctionhas to transfer the page view state.@RemoteActionmethods have to update the DOM manually using explicit JavaScript, whileapex:actionFunctionmethods automatically update the Visualforce DOM and can refresh part or all of the page, and can provide a standard interface for showing a loading status throughapex:actionStatus.@RemoteActionmethods can return data directly back to the calling JavaScript, but cannot update the page's view state.apex:actionFunctionmethods can update the page's view state and DOM structure, but cannot return data directly back to JavaScript (although you can do this with some extra effort usingoncomplete).Because of these polar differences, there is almost always "one right answer" for which method should be used in a given situation. An auto-complete-as-you-type feature would benefit from
@RemoteAction, because less data is used, and so it is faster and more responsive; we don't need to modify the view state, so this is a major bonus for the user. Updating the page's view state to show new Visualforce elements, in contrast, would best be served withapex:actionFunction; using a@RemoteActionwould force the developer to manage the DOM themselves, which can be more burdensome.Also, you generally can't modify the DOM in native JavaScript if you use
apex:actionFunction, because those changes won't appear in the view state and will be overwritten if the DOM node the changes appeared in is refreshed. This means that JavaScript designed to use@RemoteActionand update the DOM as a result will generally be incompatible withapex:actionFunction. There's exceptions to this rule, of course, as long as both uses are isolated from each other or interact only in a carefully designed order of operations.