I’m helping to build a GWT application for a client and rewrote most of the stuff to work better, shorter code, faster, etc. However in all the GUI application I’ve worked on (not so many really) there comes a flexing point where you just have to put a lot of rules and move logic from the listeners to some common mediator. Then some times this could get an ugly mess so you whatever small think you need to do in the listener.
Let’s take an example:
- form with 10-20 fields
- two exclusive radio control about half of the state of the other fields (enabling, validation, input limits)
- three exclusive radio controls control again almost the same fields, but in a different way (affecting calculations, enabling); they are also controlled by the above
- 4 or so number fields are validated on the fly depending on the previous selections and some real-time data object; they can have upper/lower limits, be enabled/disabled
- one drop-down box controls the next 6 or so controls – displaying/hiding them, modifying validators
- some checkboxes (shown by the above combo) activate some input fields and also determine their validation algorithm
While everything is up an running, without known bugs, there are a few coding gotchas that really bother me:
- code is spread among listeners and some mediator methods.
- loading the form with some preset values presents its own challenges: like data objects that might be available or not, data objects that might alter their state and subsequent field behaviour
- some fields are having a default value set and this should not be overwritten by automatic filling, but if the data objects are not there (yet) then they will need to be filled eventually when the later become available
- form cannot be submitted if any of the fields are not validated
My approach:
- identify which fields share a common afair and move code into one place
- each radio group shares a single listener implementation between its radios
- default form filling is deferred until the live data is available (as much as possible) and as a result it gets called multiple times
- each action has a call to a common validator method
- the validator runs through all the fields in the form, calls their validators (which highlight all errors) and returns a single boolean
- each relevant keypress or mouse action, data change it gets deferred to be called after 250ms from the last call; this means first call just places the validator as a delayed action, subsequent calls reset the timer
Ok, it doesn’t make any sense to dwelve into more details but I’m more upset about the fact that there is no clear separation between visual actions (enabling), data actions (setting form field values), field listeners, retrieving form values and live data listeners.
What would be a good approach/pattern (next time maybe) to make sure that MVC get separated and lends itself better to maintenance? I know this is not a typical question but I’ve read every documentation I could get my hands on and still did not find some helpful answer.
I’d move closer towards MVP than MVC. It’s clearly the way Google intends to go, so adopting it will probably mean that you’re able to go with the flow rather than fight the current.
How does this affect you? Well, I believe you should accept that a tidier implementation may involve more code: not the ‘shorter code’ you were hoping for. But, if it’s logically structured, efficient code the Google compiler should be able to trim lots out in the compiler optimisation phase.
So, move as much of the logic as you can into the model layer. Test this thoroughly, and verify that the correct level of page reset/tidying happens (all of this can be done with plain JUnit, without any UI). Next, use your Presenter (Activity) to tie the View to the Model: handling the interactions, populating the fields, etc.