On Feb 19, 2013, at 9:39 AM, Derek Atkins <warl...@mit.edu> wrote: > Geert Janssens <janssens-ge...@telenet.be> writes: > >> I don't have much experience with how this is done in general. It >> seems to me though that's a matter of defining the API's well. >> >> The GUI is supposed to know if some fields have to be >> validated. There's no way around this. But the GUI code doesn't have >> to know what the validation entails exactly. The core engine on the >> other hand does know exactly what is allowed for a given object and >> what isn't. The key is that the core engine should make some functions >> available for testing this, returning in the most simple case a yes/no >> reply (value is valid for object or not). In a more advanced set up it >> can also return a message that can be displayed to the user to explain >> why the input isn't valid. >> >> These functions are part of the core engine API and don't need to use >> any GUI framework related toolkit (like Qt, Glib, Gtk, WxWidgets >> stuff). We could keep the signal and the slots both in the GUI code, >> with the slots calling into the engine functions to do the real work. >> >> Did I understand this correctly ? > > That's how it should work, IMHO, yes. However that's not how it > currently works, and I suspect it might be a lot of work to convert > GnuCash code over to that way to doing things..
"A lot of work" is a tremendous understatement. Fortunately it can be done a little at a time, as each widget stands on its own in this regard. In my view the most important part is moving all of the business logic -- like determining if an entry is acceptable -- into the engine where it can be easily tested. View classes should be concerned exclusively with presentation and getting input; controllers should exclusively link the presentation and input to the correct engine instance, and all of the real work should happen in the engine. There's one exception: Reports have their own logic, but it's not business logic in the sense that it doesn't affect data being stored. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
