Re: [Gnumed-devel] Widgets talking to business objects

[Karsten Hilbert]

>> Exactly what in it is so poorly designed ?
> Essentially it is two mechanisms: one for the notebook, and
> another for the Clinical widget, a unified mechanism would be better.
Not always. But I agree that they should either be more
cleanly separated *OR* better unified.

>>> All our "hand-rolled" screen widgets, such as gmEditArea, inherit from 
>>> gmWidget, so that they all
>>> update their values into the common dictionary (which is a member of the 
>>> plugin object)
>> IMHO no. A GUI plugin is a GUI plugin. It should have nothing
>> to do with a business object except talking to its API.
> The dictionary is merely a convience structure (to avoid having to manually 
> extract data from each widget) Dictionaries
> are useful in talking to the Horst's style of business APIs.
That makes sense, of course. What you are saying is that every
widget that accepts user input should have a dictionary
attribute self.widget_data for easy access to it's content so
that outsiders don't need to walk the input field tree ? And
Sians PropertySupport would be one way of automatically
pushing input field content into that dictionary ?

> Actually, my intention was that for most plugins, only two methods have to be 
> written to talk to the business objects (load and save)
> we don't need to write handlers for each widget.
IMHO no. The reason being that business objects do not always
correspond with GUI objects on a 1:1 basis. One widget may
allow me to input Plan and Diagnosis both of which are
separate business objects.

I would imagine something like:

1) *during* input the input fields validate based on their
   validation rules (such as gmDateInput)
2) upon *losing focus* the input field updates it's associated
   business object's data field - whether that be achieved by
   some clever generic mechanism similar to PropertySupport or
   by explicitely defined associations executed in a
   wxValidator is another matter
3) the business object temporarily persists state in, say,
   temp files (this idea also comes from Sians earlier
   postings) such that to be able to recover from client crash
4) the business object commits either after receiving a commit
   signal (say, after the user pressed some button to that
   effect) or by itself based upon its knowledge about itself

Whether 3 and 4 happen inside the app at the local machine or
via $(TRANSPORT_OF_THE_DAY) does not matter.

Anything major I have missed here ? Is this a framework we can
work on ? Your suggestions as to exactly how to implement 3
and 4 ? At what level should we attach which mechanism ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346