Some problems have been identified with the approach of using export_for_template to export data that is sent via a webservice to the javascript.

Problems:
A) What is the context for the format_text call ? (Affects filters, languages etc). It should probably be the context of the object being formatted not the page that the JS is running on. E.g. rendering a competency name in a course, should use the system filters, but the course theme. This means every external function returning format_text data needs to accept the theme as a parameter.
B) The external functions call another API to get the data - that API could be called by other things than webservices, so it doesn't know whether to call format_text or external_format_text
C) Calls to format_text "can" add js to the page requirements because of the filters. These JS calls need to be collected and sent as data with the response
D) We need to be clearer in our separation of the model and the display - right now we are adding display properties in the model "to_record" functions - this should be done in a specific renderable for each model.
E) If export_for_data "renders" some html in the response - it cannot determine the correct renderer to use (e.g. may depend on the theme)

These issues are not so big a problem for learning plans, because alot of things are system context only - but we need to get it right as an example to other devs.