I've been stepping through the Javarosa codebase to better familiarize myself with it. The main question I wanted to be able to answer was "could large parts of the custom parsing logic be replaced with a standard library like JAXB?"
Along the way, I found large-to-mid-size tasks: for instance, XFormParser is a recursive-descent parser, when it doesn't necessarily need to be. The xml file has already been parsed into a Document object, which could be processed with a series of XPath statements directly to the important nodes in an order that makes for best readability.
I also found small, stylistic changes that could be made: for instance, XFormParser has a method called initState(). This method is only called once prior to parsing and could be moved to the constructor.
My questions are:
Has anyone else given any thought to replacing any of the Javarosa logic with standard XML utility libraries, and if so, did you already rule anything out as being an option?
Is there a process in place to enumerate and triage smaller stylistic fixes like the above? It seems like filing a github issue for each would be excessive, is there a better way to contribute these small changes?
Is there a process in place to undertake any larger refactoring tasks, and if so, are there any that are on the radar currently? Rumor has it (i.e. @LN told me) that @dcbriccetti has done some thinking along these lines, so I'd be interested to hear his (and anyone else's!) thoughts.
Has anyone else given any thought to replacing any of the Javarosa logic with standard XML utility libraries, and if so, did you already rule anything out as being an option?
I'm aware of some conversation on Slack and on GitHub over the last year. For example, https://github.com/opendatakit/javarosa/issues/17 and @dcbriccetti may remember more. The conclusion has generally been that we should make sure to have clear user-serving goals before going down that kind of path. For example, if it would help significantly with performance it might be worth it. This would require beefing up the test suite significantly.
Is there a process in place to enumerate and triage smaller stylistic fixes like the above? It seems like filing a github issue for each would be excessive, is there a better way to contribute these small changes?
I'm personally very happy with small, beginner-friendly issues being filed. In our last @TAB call we talked about formalizing guidelines and processes that have emerged organically. How granular of issues to keep and whether to encourage or discourage refactor-only work of different sizes will be areas we discuss I imagine.
Is there a process in place to undertake any larger refactoring tasks, and if so, are there any that are on the radar currently?
Again, no formal process but it's the kind of thing that the @TAB will eventually produce proposed guidelines for. So far the majority of refactoring done has been in service of immediate user goals. The process in the past year has been to share a proposed approach on a GitHub issue, get some feedback, share an in-progress pull request, get more feedback. Recent examples include
@ggalmazor separating CLI and GUI logic in Briefcase -- https://github.com/opendatakit/briefcase/pull/252. This is to separate the CLI from the logging infrastructure so users can properly see logs and still get command-line feedback. It's also to capture redundancy in business logic that will be changing.