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

[sjtan]

On Sun, 2003-05-25 at 21:03, address@hidden wrote:
> Send Gnumed-devel mailing list submissions to
>       address@hidden
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       http://mail.gnu.org/mailman/listinfo/gnumed-devel
> or, via email, send a message with subject or body 'help' to
>       address@hidden
> 
> You can reach the person managing the list at
>       address@hidden
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gnumed-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Re: Gnumed-devel Digest, Vol 6, Issue 35
>    2. re: openehr (sjtan)
>    3. Re: Gnumed-devel Digest, Vol 6, Issue 36 (sjtan)
>    4. PropertySupport (sjtan)
>    5. Re: PropertySupport (Ian Haywood)
> 
> 
> ----------------------------------------------------------------------
> 
> Date: Sun, 25 May 2003 01:32:49 +0200 (MEST)
> From: address@hidden
> To: address@hidden
> Subject: Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 35
> Message-ID: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 8bit
> Precedence: list
> Message: 1
> 
> > > > actually, I'm having a hard time trying to work out how to access the 
> 
> > > > gmclinical tables. 
> > > One of the problems may be that one needs to understand the 
> > > domain at least partially to see how this is supposed to 
> > > work. Have you read the writeup on the EMR structure ? 
> > >  
> > Where's the write-up? 
> client/doc/TODO/developer-guide.txt 
>  
> > I suppose my problem is with the distinction between Diagnosis , and 
> > Clin Health Issue which seems to be something to hold arbitrary  
> > text of 128 character, and be associated with a clinical episode which 
> ... 
> IMHO, to a doctor the whole thing makes sense, semantically. If you need
> more explanation after 
> reading the writeup please ask again. 
>  
> > First of all, the doctor 
> > would need a pretty good retrospectoscope to figure out which items 
> > occuring at an encounter actually were part of a long running episode 
> > regarding a particular issue 
> No, this type of thing feels perfectly natural to a health professional (or
> should). 
>  
> Karsten 
>  
> 
> -- 
> +++ GMX - Mail, Messaging & more  http://www.gmx.net +++
> Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
> 
> 
> 
> ------------------------------
> 
> Date: 25 May 2003 10:45:26 +1000
> From: sjtan <address@hidden>
> To: gnumed <address@hidden>
> Subject: [Gnumed-devel] re: openehr
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> MIME-Version: 1.0
> Content-Transfer-Encoding: quoted-printable
> Precedence: list
> Message: 2
> 
> 
> it's changed, some stuff available now.
> Looking at the reference data_structures_rm_1_3.pdf document,
> it's very Eiffel oriented;
> looking at the table structures, even the datatypes functions are
> defined
> 
> TABLE_S
> ------------------
> def row_count()
> def column_count()
> def row_names()
> def_column_names()
> def ith_row(i)
> def has_row_with_name(key)
> def has_column_with_name(key)
> def named_row(key)
> def has_row_with_key(keySet)
> def element_at_cell_ij(i, j)
> element_at_named_cell( row_key, col_key)
> 
> and these are the encoding rules:4.2.4.2   =20
> 
> TABLE_S Structural Encoding Rules
> The TABLE_S encoding rules are as follows:
> =B7    Each column is represented by a COMPOUND, whose name value is the
> name of the column.
> =B7    Each row item in a given column is represented by an ELEMENT under
> the relevant column
> COMPOUND.
> =B7    The name of each ELEMENT object is the name of its column.
> 
> 
> something like
> 
> name =3D 'name'
> index =3D 'index'
> value =3D 'value'
> 
> table.cols =3D []
> for x in range (n_cols):
>       COMPOUND =3D { name: col_names[x], items =3D [] }
>       table.cols.append(COMPOUND)
>       for y in range( n_rows):
>               ELEMENT =3D { name : col_names[x], index : y, value =3D None    
> }=20
>               COMPOUND.items.append(ELEMENT)
> 
> 
> 
> Does using OpenEHR structures invalidate GPL ?
> 
>               =09
> =09
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Date: 25 May 2003 10:59:40 +1000
> From: sjtan <address@hidden>
> To: gnumed <address@hidden>
> Subject: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 36
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Precedence: list
> Message: 3
> 
> On Sat, 2003-05-24 at 20:51, address@hidden wrote:
> > Send Gnumed-devel mailing list submissions to
> >     address@hidden
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> >     http://mail.gnu.org/mailman/listinfo/gnumed-devel
> > or, via email, send a message with subject or body 'help' to
> >     address@hidden
> > 
> > You can reach the person managing the list at
> >     address@hidden
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Gnumed-devel digest..."
> > 
> > 
> > Today's Topics:
> > 
> >    1. Problems installing gnumed (Roberto Mello)
> >    2. Re: Problems installing gnumed (Horst Herb)
> >    3. Re: Problems installing gnumed
> >    4. Re: Gnumed-devel Digest, Vol 6, Issue 35 (sjtan)
> > 
> > 
> > ----------------------------------------------------------------------
> > 
> > Date: Fri, 23 May 2003 13:51:21 -0600
> > From: Roberto Mello <address@hidden>
> > To: address@hidden
> > Subject: [Gnumed-devel] Problems installing gnumed
> > Message-ID: <address@hidden>
> > Content-Type: text/plain; charset=iso-8859-1
> > MIME-Version: 1.0
> > Precedence: list
> > Message: 1
> > 
> > Hello,
> > 
> > My name is Roberto Mello and I'm evaluating GNUmed for my mom's clinic.
> > It's been my dream to use a free (speech) medical system for my mom's
> > practice, and I think GNUmed is such system.
> > 
> > I'm from Brazil so I'd be translating the system to portuguese as well as
> > helping with development and bug fixing where necessary. I'm an
> > experienced developer, although not so much with wxPython yet.
> > 
> > I haven't been able to install GNUMed fully<F5>. I loaded the three sql
> > files described on the documents, but when I run it I get a PANIC after
> > logging in:
> > 
> > [PANIC]
> > (/home/rbm/documents/projects/gnumed/gnumed/client/python-common/gmPG.py::run_query:497):
> > query >>>SELECT description from v_i18n_enum_encounter_type;<<< failed
> > 
> > I've grep'ed around for that table and I found it, but I don't know how
> > it's supposed to be loaded (the sequence, that is).
> > 
> > I'm using GNUMed from CVS of a couple days ago.
> > 
> > Is there an update page somewhere where I cansee the state of the several
> > modules of gnumed? Right now I'm more interested in the patient tracking
> > capabilities of gnumed than in its decision-support features.
> > 
> > Any help and guidance would be appreciated. I'd really like to free
> > ourselves from the proprietary system we are forced to use at the moment.
> > 
> > -Roberto
> > 
> > -- 
> > +------------| Roberto Mello - http://www.brasileiro.net |------------+
> > Computer Science, Utah State University  -    http://www.usu.edu
> > USU Free Software & GNU/Linux Club       -    http://fslc.usu.edu
> > OpenACS - Enterprise free web toolkit    -    http://openacs.org
> > Pimentus annus alter, refrescum est.
> > 
> > 
> give us a hand:  
> 1. assume you are the sole developer of the domain (one level of
> indirection) layer between the gui and frontend. 
>   Implement the layer, the connection adapters to the frontend
> components, and the layer adapters to the "current" database. 
> (only 3 layers spanning the whole gui system, not much really)
> 
> 2. autocratically allow or deny changes to your domain system.
> 
> 3. do it in 2 weeks.
> 
> that's all we ask of you.
> 
> 
> 
> 
> ------------------------------
> 
> Date: Sun, 25 May 2003 13:08:08 +1000
> From: sjtan <address@hidden>
> To: gnumed <address@hidden>
> Subject: [Gnumed-devel] PropertySupport
> Message-ID: <address@hidden>
> Content-Type: text/plain
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7BIT
> Precedence: list
> Message: 4
> 
> 
> 
> I've made a PropertySupport class like java.beans.PropertySupport.
> 
> There is a PropertySupported class in the file, which can be used
> to notify assignments to a class instances self.
>  
> 
> If the gmEditArea was reverted to it's old simple, 
> self.txt_blah = wxTextCtrl 
> self.btn_OK = wxButton
> 
> then those component creations can be detected, but only if 
> assigned to the self that is a PropertySupported class.
> 
> 
> you can easily add widget construction event detection to the gui
> construction. 
> 
> It is also possible to detect the TBOX_list assignment , but
> the TBOX would have to be from a UserDict subclass that inherits
> PropertySupported. 
> 
> 
> - Look, prior to the recent changes in gmEditArea , all the fields
> in the panel were signalling through  handler classes which put the
> changes into a dictionary. The easiest thing to do then was to 
> make a dictionary that could update a database e.g. by calling
> myDict.save() or something like that, and then instantiating that 
> dictionary as the dictionaries for the handlers. 
> 
> Now that is broken by the re-write of gmEditArea ;  so I'm asking if 
> anyone is unhappy about the property support idea, before I waste my
> time again.
> 
> 
> - this property support mechanism was intended to be used for connecting
> domain classes together, but I noticed it had the possibility of working
> for the problem of extracting the data entry components from a cleanly
> written prototype gui, so that adapters (wxValidator) can be added to
> the components , which can then communicate with the database or a
> domain model .
> 
> 
> 
> 
> 
> ------------------------------
> 
> Date: Sun, 25 May 2003 16:15:52 +1000
> From: Ian Haywood <address@hidden>
> To: address@hidden
> Subject: Re: [Gnumed-devel] PropertySupport
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: multipart/signed; protocol="application/pgp-signature";
>  boundary="=.JbmnZ1_vl4e)w:"
> MIME-Version: 1.0
> Precedence: list
> Message: 5
> 
> --=.JbmnZ1_vl4e)w:
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> 
> On Sun, 25 May 2003 13:08:08 +1000
> sjtan <address@hidden> wrote:
> 
> > 
> > 
> > I've made a PropertySupport class like java.beans.PropertySupport.
> > 
> > There is a PropertySupported class in the file, which can be used
> > to notify assignments to a class instances self.
> >  
> > 
> > If the gmEditArea was reverted to it's old simple, 
> > self.txt_blah = wxTextCtrl 
> > self.btn_OK = wxButton
> > 
> > then those component creations can be detected, but only if 
> > assigned to the self that is a PropertySupported class.
> 
> To be honest, I'm  still having a lot of trouble understanding this.
> (I've never used Delphi or any of those things, the last time a
> wrote a non-UNIX program it was still called Turbo Pascal ;-)
> 
> Apparantly, you are trying to parse the existing code to construct template 
> files
> for event handlers on the various widgets. Is this right?
> 
> Could you also, for those ignorant, explain what java.beans.PropetrySupported 
> does? 
> 
> 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).
> 
> In addition, the current plugin system is poorly designed, as has been 
> commented on before, and 
> will be reworked in the (hopefully) near future. This would be a good time to 
> make sure Syan's
> work is intregrated with the overall plan, so it doesn't get broken again.
> 
> Proposal:
> 
> 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)
> Other widgets will be multiple inheritors of gmWidget and the wx original, to 
> provide
> this functionality to all widgets we use (even if they are otherwise ordinary 
> wx widgets)
> 
> [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?]
> 
> Plugins then only need load () and save () methods to move the dictionary 
> values to and from the 
> backend database as Syan said.
> 
> load () would be called on "patient_selected" (perhaps as a "lazy" function 
> -- only when the plugin
> is shown onscreen)
> 
> save () is more complex, perhaps the inherited behaviour should be a few 
> seconds after the last widget is updated 
> (or prior
> to another load () if it comes first), For the scripts widget at least, a 
> specific button/function key
> is needed also (in order to save and clear the fields for the next 
> prescription)  
> 
> Ian
> 
>    
> 
> --=.JbmnZ1_vl4e)w:
> Content-Type: application/pgp-signature
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> 
> iD8DBQE+0F+eKPy8UudQZS4RAo2qAJ96JivK2Qs2FFMMAtCZxwkkTl5piwCgg4IP
> 0NtgWqiXWetl1O3qDuEElnU=
> =GvgL
> -----END PGP SIGNATURE-----
> 
> --=.JbmnZ1_vl4e)w:--
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel
> 
> 
> End of Gnumed-devel Digest, Vol 6, Issue 37
> *******************************************
It makes an object "push" state changes. when an attribute changes, e.g.
o.x = 1,  then an event with name "x" , oldValue = None, newValue = 1 is
pushed onto any listeners (via their propertyChange(event) method)
registered with the object. 

        It was useful in java, so I put in , but it probably isn't necessary ;
you could just get a gmEditArea object and go through it's __dict__
method to find all the correctly named components starting with txt__ ,
and attach wxValidators to them , say a validator with a table name and
a field name which updates a database table when wxValidator.validate is
called , or just attach a eventHandler object instead which handle text
events. 

  Actually , in not sure in wxWindows, but in java, you could get the
topmost container, and recursively call getComponents() and test the
type of each component. if a component is a container, recurse and 
call getComponents(), otherwise test if the component is a particular
type, get it's name, and attach a e.g.textListener (text event handler)
to it.


>Apparantly, you are trying to parse the existing code to construct
>template files
>for event handlers on the various widgets. Is this right?

The script idea was just to automate the writing of event handler
drudgery ; it's just about "separation of concerns" 
( I'm beginning to think this is a way computer programming
educationalists push their consulting fees). 


Look I've got another idea I'm trying out ;

I was playing with the java ant build system, reading about
Hibernate and Xdoclet, and was thinking why don't we 
try this attribute programming thing, 
and have a application generator program that reads a xml script the
defines a tree structured data structure, and a tree structured 
view structure, and have required actions as attributes in each
view. 

I'll post the idea as appgen at the client , server  directory level.

Whether we could do it , or we all independently do it ( just for fun),
is another matter.