Open Issues for JavaRosa Conference 7/20-23

Good Refactoring Candidates

Splitting the current data model into static and dynamic components (much like the original FormDef/DataModel split). With repeats, a lot of the static information from the FormDef was moved into the DataModel. This created redundancy in that the data model was meant to encapsulate only the data that changes from form to form. It also makes answering basic questions about the data model (such as 'is node x repeatable') very hard to answer, due to the mixture of dynamic and static data.

Deploy ultra-lightweight serialization format for saved forms. This would be essentially serializing only the 'dynamic' portion of the data model. Would be much easier to implement if (1) is done first.

In FormDef, cleaner handing of select choices particularly with internationalization

Cleaner code for FormIndex and iterating in various ways through the form. Also: more unified handling of TreeElement vs TreeReference (in a lot of places right now they need to be passed around and managed in tandem).

Change parser to use push-parsing (whichever is the kind where you don't create the whole DOM in memory)

Overall, I think our shell/activity paradigm is pretty good, but we need to better flesh out:
sets of activities that are closely related; currently all glue has to go through the shell, perhaps it should be contained within the 'head' activity within the group. this is essentially activities acting as shells themselves ('subshells')
the workflow() method in the shell gets very unwieldly, mostly doing the same kinds of things. we need a workflow toolkit or utility library that can more easily manage the common workflow transitions.

JRSP, services, StorageManager, et. al. -- not sure this panned out to provide the value we thought it would