Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 37

[Karsten Hilbert]

> Having separate handlers may not be advantageous if the idea is to throw
> away the widget when you have a better one. 
What I really *liked* about the handler thing is that it
*generated* code that we did not have to write. My trouble was
with *understanding* and I wasn't sure whether the code it
generated was the code we wanted, conceptually.

> I don't know if is true or not, but model view controller separation is
> supposed to help maintain code , ? easier to change. But that's what I'm
> told, and I'm not certain of in practice. If you bind the widget with
> its method of updating the database,
Personally I would not like this. UI widgets should have no
business meddling with the DB. They may, however, offer their
opinion as the when it is opportun for the business object to
go about its business of database interaction. Whether the
business objects cares enough about what the UI says, is
another matter. In principle I do hope we separate into UI,
business and storage which AFAICT we do: UI = widgets,
business = client/business/ and friend, storage = PostgreSQL.
(well, the last layer is a weak argument :-)

> binding the database access to the widget means you can find the
> database access code where the widget is;
IMHO, this is an impedance mismatch. A meaningful GUI object
need not map onto a meaningful business object 1:1.

> What do people think : does anyone want to try this ? Should I try it
> (if nobody wants to) ? 
It sounds reasonable. I am surely in favour of "generic"
mapping code between input fields (say, in an edit area) and
their corresponding business object data fields. IOW, I like
the concept of an interface.

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