gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] GNUmed plugin development - part 5


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] GNUmed plugin development - part 5
Date: Mon, 13 Apr 2009 13:11:18 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, Apr 09, 2009 at 09:36:17AM +0200, Hilbert, Sebastian wrote:

> I opened /home/user/source/gnumed/gnumed/client/wxg/wxSoapPluginPnl.wxg and 
> started to changed it to my fit my needs. I then saved it as 
> /home/user/source/gnumed/gnumed/client/wxg/wxCardiacDevicePluginPnl.wxg

To rather be safe than sorry and to encourage best practices
it is prudent to suggest reversing the steps:

- "save as" under the new name (could be done at the filesystem level, too)
- *then* edit it and save changes

It is all too easy to hit save while editing thereby
overwriting the original source.

> What you can see here is the complexity we are getting into.
Visual complexity. That's fine. A key point to remember for
successful implementation: simplify, simplify, simplify.

> There can be more 
> than one device not to mention a combination of active and inactive devices. 
> Active and inactive leads.
Does all this really have to be stored in computable form
(for now anyway) ?  Maybe structured text serves well
enough for some of it ?

> Why is all this important ? Because the life of a 
> patient may depend on it. Hospital might call in and ask how long the leads 
> have been in to decide whether to cap or extract a lead. There should be a 
> device history.
History sounds a bit like free text might do.

> It is important to know which of you patients have which leads 
> and generators when a recall is issued.
That sounds like searchability for specifics is wanted. This
usually tends to ask for structured data storage. Still, for
the first time around. Might it be OK to go with text and
maybe lend some pre-definable structure to it (use of text
macros etc) ?

> Now that we have a GUI we need to produce python code for it. There is a 
> feature in wxglade to produce python code. This will be described in the next 
> part.
Best practice again: inside your new .wxg file be sure to
edit to Python code output path before generating the code
-- or else you will overwrite the Python code generated from
the source .wxg file... (no problem, it can be regenerated).

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]