Extend Fluid model accessors (fluid.get) to support access through any form of "direct model" in place of "EL"
Description
Plain EL paths are an awkward form to express the "coordinates" of a part of model indirected through a general query. Where the "coordinates" of the required state in the model require variable numbers of arguments or an irregular sequence, "escaping" all of the coordinate details to a flat string creates a fragile and unreadable representation. It would be preferable to express these forms of "coordinate models" (that is, "coordinates OF models, expressed as a model", also known in the context of DataSources, as "direct models") in JSON form. The fluid.get pathway needs to be upgraded to support suitably structured JSON supplied as the "EL" argument, as well as a system for configuring an expandable collection of "resolvers", which are "typed machines for resolving coordinate state". This functionality also relates to the upcoming functionality for expressing model transformations - the collection of "resolvers" should be possible to view as, or transform into, a configuration suitable for a model transformation as operated by the "options chewing framework".
Environment
None
Attachments
1
Activity
Show:
y z May 17, 2011 at 3:53 PM
The test case is now passing and the issue can be resolved.
Antranig Basman February 4, 2011 at 8:40 AM
Resolved with new implementation at what is now git revision 1971f9a.
y z January 21, 2011 at 6:22 PM
failing.test.patch.txt has a test with an empty model.
Plain EL paths are an awkward form to express the "coordinates" of a part of model indirected through a general query. Where the "coordinates" of the required state in the model require variable numbers of arguments or an irregular sequence, "escaping" all of the coordinate details to a flat string creates a fragile and unreadable representation. It would be preferable to express these forms of "coordinate models" (that is, "coordinates OF models, expressed as a model", also known in the context of DataSources, as "direct models") in JSON form. The fluid.get pathway needs to be upgraded to support suitably structured JSON supplied as the "EL" argument, as well as a system for configuring an expandable collection of "resolvers", which are "typed machines for resolving coordinate state". This functionality also relates to the upcoming functionality for expressing model transformations - the collection of "resolvers" should be possible to view as, or transform into, a configuration suitable for a model transformation as operated by the "options chewing framework".