server_method applies to a record and returns a value computed on that record from the server, finder_method applies to a scope (all a model class) and returns a single record from that scope.
Each of these mechanisms are similar in that they execute on the server and return values to the client. The improvements are to
(a) figure out how a server_method can automatically be refetched: ...
certainly when the record is changed the server (and client is notified) the client should request a refetch.
there is also currently a ! extension to server_methods that forces a refetch, but using this is not too clean. Somehow after the record is changed locally on the server during some logical points in the UI lifecycle we should be able to request that any server_methods associated with the record be recomputed. This has to be somehow done on request however, not EVERYTIME the record changes locally. For example say a record has some column that is updated by the user typing into it. We will probably want to wait till the user changes focus before recomputing, otherwise we are going to do a roundtrip to the server on every keystroke. Perhaps model_instance.update_server_methods (alias update_server_method) which takes a list of method names to update. If method_names is empty then it does all currently active server_methods.
(b) figure out how finder_method can be extended return an aggregate value rather than a record. In otherwords its actually a new method aggregator that applies to a scope (including the default scope) and does some computation on that scope and returns a jsonizable value. Its very similar in the mechanism that finder_method uses, except where finder_method internally returns a single item collection containing the record, in this case we would return a jsonizable object tree. Probably it should use the same mechanism scopes use to specify that the computation has joins in it, so that we know when to recompute.
server_methodapplies to a record and returns a value computed on that record from the server,finder_methodapplies to a scope (all a model class) and returns a single record from that scope.Each of these mechanisms are similar in that they execute on the server and return values to the client. The improvements are to
(a) figure out how a server_method can automatically be refetched: ...
certainly when the record is changed the server (and client is notified) the client should request a refetch.
there is also currently a ! extension to server_methods that forces a refetch, but using this is not too clean. Somehow after the record is changed locally on the server during some logical points in the UI lifecycle we should be able to request that any server_methods associated with the record be recomputed. This has to be somehow done on request however, not EVERYTIME the record changes locally. For example say a record has some column that is updated by the user typing into it. We will probably want to wait till the user changes focus before recomputing, otherwise we are going to do a roundtrip to the server on every keystroke. Perhaps
model_instance.update_server_methods(aliasupdate_server_method) which takes a list of method names to update. If method_names is empty then it does all currently active server_methods.(b) figure out how finder_method can be extended return an aggregate value rather than a record. In otherwords its actually a new method
aggregatorthat applies to a scope (including the default scope) and does some computation on that scope and returns a jsonizable value. Its very similar in the mechanism that finder_method uses, except where finder_method internally returns a single item collection containing the record, in this case we would return a jsonizable object tree. Probably it should use the same mechanism scopes use to specify that the computation has joins in it, so that we know when to recompute.