[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] PropertySupport
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] PropertySupport |
Date: |
Mon, 26 May 2003 03:14:26 +0200 |
User-agent: |
Mutt/1.3.22.1i |
> Another problem is most (actually, virtually all) of gnumed UI code is
> contained
> as plugins. Plugins are meant to be self-contained items of code, ideally one
> file,
> to do a specific job. Users can load and unload modules at anytime. A
> separate file
> to hold handlers complicates things, as it has to be loaded/unloaded in
> unison with
> its 'original' plugin file (but certainly doable).
IMHO, this is achievable by importing a plugin-specific handler file
in the plugin code and del()ing it upon deregister()ing.
> In addition, the current plugin system is poorly designed, as has been
> commented on before,
Exactly what in it is so poorly designed ?
> 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.
> [can this end the need to scan files and add handlers in a separate file?
> Each widget could handle all of its
> own events. Or am I missing something?]
I guess yes it can. Teaching our widgets how to talk
generally to business objects is a good idea and can well be
done via a common ancester - or rather mixin in this case.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: [Gnumed-devel] PropertySupport, Karsten Hilbert, 2003/05/26