Beyond 2.6

[John Ralls]

On Feb 14, 2013, at 10:43 AM, Derek Atkins <warlord at mit.edu> wrote:

> Christian Stimming <christian at cstimming.de> writes:
> 
>> Am Mittwoch, 13. Februar 2013, 13:07:55 schrieb Derek Atkins:
>>> John Ralls <jralls at ceridwen.us> writes:
>>>>>> What do you mean by "real-time validation of inputs"?
>>>>> 
>>>>> I mean, e.g, making sure an Account has a name entry, and that it's
>>>>> unique, and that the account type is valid based on the parent.. 
>>>>> Those
>>>>> kinds of input validation that's currently done in the dialog.
>>>> 
>>>> Those checks should be part of the Account constructor, and would
>>>> throw exceptions. The interface code between the engine and Gtk+ would
>>>> convert those exceptions into GErrors for the dialog box to handle;
>>>> C++-based UI frameworks would be able to catch the exceptions
>>>> directly.
>>> 
>>> Except by the time you're processing it's too late.  It would be nicer
>>> to make the "OK" box grey until the dialog is properly filled in, to
>>> provide validation of inputs even sooner to the user.  But that implies
>>> some way to push the validation requirements into the GUI.
>> 
>> Absolutely. The constraints are needed on several levels. Of course
>> constraints in the lower data layer (or database layer) are needed to
>> enable unittesting and consistency there. But as the goal is a
>> user-centric application, the constraints must be communicated to the
>> user in a way that makes it easy for him/her to understand those
>> constraints. At the end of the day, this means the GUI must contain
>> the knowledge about those constraints just as well as the data
>> layer. A question of what we're doing this for, after all.
> 
> Right.  It would be nice if there were some way to abstract out those
> constraints in a way that both the "model" and the "view" (and arguably
> the "controller") can share the validations.  I'm not sure how this can
> best be done or implemented, tho.

There is. It's what MVC is all about: The model class implements (e.g.)"check for duplicate names". The View object gets the Account Name string and passes it to the Controller object, which then asks the Model object whether it's OK. If it's not, the Controller object tells the View object to indicate an error. When all of the required fields are filled acceptably, the Controller object tells the View object to enable the OK button. All of the "business logic" then lives in the Model classes.

Gnucash isn't written that way, but it can be fixed. It just takes someone to do the work -- though if we want it done in our lifetimes, several someones.

Regards,
John Ralls