I've just realised that effectively I'm breaking my own rule of thumb No.4 "You don't need to write an application framework", and here I am writing one.
So I need to clarify this, partly for my own sanity, and investigate why I'm doing this. To start with the rule of thumb No. 4, looking back what I meant was simply "when faced with building something that is new and confusing, it is a big mistake to start off by writing a framework because that's the only way to begin". In this sense, and fortunately, ZXAF falls outside of the rule because I'm pulling together various bits of code that have been around, in production use, for many years.
What I'm doing with ZXAF is taking all the various bits of good code and putting them together in a coherent manner to get rid of what I call the middle-aged code spread. This is something that I've observed happening often. You start off with a nice tight set of classes and a good design, and as real world pressures (i.e. delivery) creep in there simply isn't time to rework the design to make it able to handle a new requirement, so it's more expedient to add something that is similar but different to something that was already there.
This is exactly how I ended up with my ZXAF Views and Forms problem whereby the view and the form should have been one thing but actually the Form came first and then the View came along. Neither were right, the Form was good a presenting a Form (i.e. two column form with prompt and value of a single entity), and the View was excellent at displaying a row per entity based on an iterator. To further confuse things the View had started out life as a Form and then been heavily modified to fit a specific project requirement. The View introduced the concept of Items and Transformations, but didn't really support editting.
The net result was that both items had to be reworked because neither of the two classes individually were good enough. The end result is the View class that is now present in ZXAF.
The resulting design (the View) is the results of a code evolution of stable code being reworked (or refactored for the buzzword conscious).
This single case really illustrates what ZXAF is all about; reducing and producing something that is more consistent and coherent. There are still areas of general ickkiness within ZXAF as it is an evolving entity rather than being a rush to publish.
In conclusion I don't consider that I've broken my own rule, (MRDA applies).