I’m looking for best practices for sophisticated UI logic implementation. I’m working on a Windows Forms application, but I believe there should be generic patterns for solving this problem on any platform.
I have a number of controls on my form, there are lists, buttons, tables and a tree view. So, the idea is that depending on “context” some of the controls are enabled, while others are disabled. Some of them can provide some features for the moment and others don’t.
Currently it’s implemented “as is”. I handle events, check for changes (new tree node selected, couple of nodes selected, etc.) and then decide whether some of the controls need to be disabled or enabled. I don’t really like this approach because the Form code looks to complicated. And if I need to add more logic, it becomes even more complicated. I’m really concerned, since we’re quite agile and new features or lots of changes are the daily norm.
I’m thining of separating all this logic into parts (Features), where each feature is an object that know how to check its state, and depending on this state, enable or disable the related controls.
Don’t really want to invent anything new and trying to find any good ideas that are widely used. Please, don’t recommend single UpdateUI() method approach, I believe that won’t change anything in the long term.
Thanks.
This blog series may be what you are looking for:
http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/
(may look like a lot of material, but start just with the “Humble Dialog box”, based on Michael Feathers great article). This is all about “how to separate your logic from your UI code”, which may solve most of your problems.