[wxruby-users] sample desktop app

[Alex Fenton]

Nathan Macinnes wrote:

> John, thanks for the heads-up. I do plan on sticking to MVC as much as 
> possible... I'm not quite sure what that looks like yet though.
>   

I think John's advice was sound. I've never sat down and read a book 
about MVC and I'm not a professionaly programmer, though in a previous 
life I did a lot of web programming in Perl. But I can say what enabled 
Weft QDA to go from a specialised and limited program to something to 
which its now quite extensible - I mean, that I can add quite radical 
new features to without breaking lots of stuff. It probably roughly fits 
an MVC model...

M: your non-GUI classes stand alone and can be unit-tested. So you know 
that the objects you're going to display (in Weft, Documents, 
Categories, Text Fragments, etc) can be created, changed, saved and 
restored without problems. This means you don't waste time clicking 
round in a GUI to fix issues with databases or how they translate to 
ruby classes.

V: Your GUI code is strictly separate - in Weft, it's all in a wxgui 
directory. All the GUI code deals with layout (whether that's through 
XRC, some kind of sugary syntax, or bog-standard wxRuby code - Weft uses 
all three) and event handling. The sort of logic that deals with saving 
non-GUI objects, and updating related objects should be outside the GUI 
code. So you say:

def on_click_ok
  document.title = gui_text_box.value
  document.save
rescue BadDocumentTitleError
    display_gui_error_message "The title was invalid"
end

The validation, and the mechanics of how the object is saved are hidden 
from the GUI code. It just has to know how to deal with errors.

The biggest jump for Weft was separating the GUI code that made changes 
to objects, from the GUI code that updates the state of objects. 
Otherwise every place that changes a database object has to know about 
every place that that object might be displayed. This quickly becomes 
impossible, and you get endless problems with stale/inconsistent object 
data being presented to the user.

One way of tackling this is to use Observer: when an object is saved, 
all interested GUI representations are informed and deal with the new 
state of the object (eg a new title) accordingly. Another is using 
wxRuby's UpdateUIEvent - this is handy when, for example, you want menu 
items to be enabled or disabled based on a criterion, but don't want to 
have to keep track of that every time it changes, just when the relevant 
menu item is displayed.

So, if you want a "Save" menu item that is only active when there are 
unsaved changes in a model object called document, you can do something like

evt_update_ui(Wx::ID_SAVE) { | e | e.enable(true) if 
document.has_unsaved_changes }

hth
alex