I was discussing with Devin that applications should be able to resolve tickets that are functions. They could resolve standard types such as a Table, or to custom types like a model that is a composition of several standard types. My mind keeps wandering to the idea of a "LayoutWidget", or the like, which is a templated layout that an application can generate to describe an "application window".
In the first version of app mode, an application can export a custom field that is this factory method. Today, this is then accessible via a REPL, but not accessible via ticket resolution.
An improvement on this idea is not just to resolve these parameterized tickets, but also to describe them somehow to the UI. Potentially the ui could pop-up the template params (even possibly populating them with results of a selectDistinct! or some form of application-implemented auto-suggest trie), and fire off a request that looks more like a FlightDescriptor path (aka REST-like) than an opaque ticket.
Current app mode exports Field<T> objects; maybe these could be formalized as FieldFactory<T>
I was discussing with Devin that applications should be able to resolve tickets that are functions. They could resolve standard types such as a Table, or to custom types like a model that is a composition of several standard types. My mind keeps wandering to the idea of a "LayoutWidget", or the like, which is a templated layout that an application can generate to describe an "application window".
In the first version of app mode, an application can export a custom field that is this factory method. Today, this is then accessible via a REPL, but not accessible via ticket resolution.
An improvement on this idea is not just to resolve these parameterized tickets, but also to describe them somehow to the UI. Potentially the ui could pop-up the template params (even possibly populating them with results of a selectDistinct! or some form of application-implemented auto-suggest trie), and fire off a request that looks more like a FlightDescriptor path (aka REST-like) than an opaque ticket.
Current app mode exports
Field<T>objects; maybe these could be formalized asFieldFactory<T>