This is an informational message to describe how XRC made a potentially bothersome task quick and easy.
I'd built a small application to maintain a database table, keeping it consistent with some other tables. It consisted of some text boxes, spinners, choice boxes, and buttons, together with 12 customized calendar controls. I'd used XRCed to create and lay out the UI, including some subclassing and a resource handler for the subclass that manages the calendars. It took a while, but it's been working nicely.
Now I need to maintain another, similar table. I've chosen to put the two UIs into a notebook, since they're somewhat related and the user may want to switch back and forth between them.
My first step was to create a 2-page notebook, then embed the previous UI into the first page. Using XRCed, that turned out to take a minute or two with cut-n-paste from the original .xrc to the new one. With a bit of trepidation, I replaced the old file with the new one where the app could see it, and fired up the app. Works fine, first time, no source code changes! The notebook shows, I can switch pages, use the app, everything's copacetic.
I believe that this is due to the fact that the app only "knows about" the XRC file, and the particular named nodes in it that need to be dealt with -- everything else is managed under the covers. Off the top of my head, I'd say in MVP terms that the View has been pushed into the XRC resource, leaving the app code to be mostly pure presenter (ignoring the model that the app initiates and manages). One difference is that the Presenter in this case contains the Observer of the model; when notified by the model, it makes changes to the appropriate View elements.
Summary: if you're interested in clean separation of concerns between the details and layout of the UI and the behavior of the application, check out XRC.
Don Dwiggins
Advanced Publishing Technology