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

[sjtan]

> --=.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?]

Having separate handlers may not be advantageous if the idea is to throw
away the widget when you have a better one. 
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 , it might  make both the widget and
the database update less re-usable, but in this situation, no one really
cares. (the database is small, there is hardly any reuse between a
facilitated problem input , and say , a drug or allergy lookup ; binding
the database access to the widget means you can find the database access
code where the widget is; ) so probably in this case, it's a toss up
whether to separate the handler or not. I could also admit that maybe
it's a misapplication of MVC , because the handler code is really the
adapter between the model and the view : e.g. you can't reuse a
textEvent listener with a combobox event or list event listener. 


> 
> 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

Files are "new" and "save", so "save" leaves the current prescription
for editing until "new" or "save" again. "delete" could be a button with
a R-U-Sure prompt, or a right-menu item over a list item selected.
You could just make a generic ListAndForm widget, which is configured,
with a model interface of

        getFieldNameAssociation() - a list of tuple of (display_name,
                                                item_attribute_name)
                                the first time this is called, the
                        widget uses it to display the labels and the            
                                        fields. 

        list = getHelperList( fieldName, fieldValue)  - a help list,
                                                used for some sort of 
                                                smart text control.
                                        list is None if there is no
                                        helper for the fieldname.

        
        value = getValue( fieldName, selectedHelperListValue) - the             
                                field
value after a 
                                        helper list item is selected
        
        list = getListItems()   - the list of created items for this 
                                   record.
        notifyListChanged()     - notifies an external list                     
                        change(rarely   )
                                so getListItems can be called again
                                by the widget.

        item = newItem()        - a data item 

        save(item, changedFields) - saves the data item , only updating
                                        the changedFields. If the item
                                        is a new item, it will return
                                        with an id attribute.  

        delete(item)            -  discards if no id, else delete it.

the model being implemented differently for each different root_item
type one is editing (see , I can be flexible about the terminology).
You could use this for Allergy, Medication, Past History, etc.. and most
of gmEditArea cases , I think.

What do people think : does anyone want to try this ? Should I try it
(if nobody wants to) ? 

If the interface idea is good, but the actual interface isn't, someone
else propose another.