Re: [Gnumed-devel] SOAP2.py questions from Richard

[Carlos Moro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Ian Haywood wrote:

|> While in fact I do like the approach a lot. Carlos has already
|> started to use it in writing a SOAP entry plugin for HorstSpace.
|
| Excellent, but please don't pointlessly duplicate this work. Speak
| up if you want something changed.

The idea is  use SOAP2.py widget as the key input element of the SOAP
input plugin. I comment the initial approach/proposal, as commented
with Karsten, including with his feedback  ;) :

~    -It would be mainly a split  window:

~    A) On the right: gmEMRBrowser: allows problem selection. Only a
new SOAP input control can be created when selecting for input a new
problem. For future:  tree will allow more sophisticate SOAP
navigation/edition/selection, according patient's EMR.
~    B) On the left:

~ 1. MultiSash seems the adecuate base widget for our SOAP entries.
It's completely implemented in python (wxPython/lib/multisash.py),
looks really nice and is very effective splitting views.

2 . When a new split view is created a new instance of the target
class is created. Perfect for us: create an instance of cSOAPControl
and pass to it the currently selected health issue in the tree (we can
improve selection in future).

3. There would be a unique pair of clear/save buttons in the plugin.
The user must
be really sure wich problem currently selected SOAP belongs to.
Multisash provides a
yellow border in the active split, so doesn't seem too difficult. The
plugin will query
the controls for the input and dump to the backend (interacting with
gmClinicalRecord)

4. To improve usubility, only horizontal multiusash splitting will be
allowed,
disabling vertical. In that way, SOAP input controls will
be displayed like in one column from top to bottom.

5. In order to allow another split SOAP creation (initially by
dragging the sash creator, we can later improve with the + button), we
could check that a problem in the tree is selected, and it must be
different of the problems of the other cSOAP input views. Also, we can
limit the total views to 3 or 4...

6. Regarding implementation, we could at first take multisash.py
and customize to adapt to our needs. In future we can always decide to
extend or something to make our approach more generic...

I attach a shot of a very first try, yet using old SOAPCtrl...(just
for the general idea...)
We are synchronized and in contact to advance both SOAP2.py and
gmSOAPInputPlugin... :)


Best regards,
Carlos


|
|> One thing I am wondering about is: How are we intended to deal
|> with data having been typed into a functional popup ? Eg. imagine
|> the user incantates the magic string that pops up the
|> vaccinations control. After completing that control the user
|> clicks OK. What happens next ? One thing is that we do want to
|> drop a quick note about the vaccination into the SOAP widget.
|> OTOH, we would also want to store the vaccination details into
|> the database. Do we do this immediately when OKing the
|> vaccinations popup ? If so how do we handle the case when the
|> user CANCELs the master SOAP control ? If not where do we keep
|> that information around and until when ?
|
| Three options: - parseable string, when we commit the SOAP, we
| parse the text and do the database commits. We can mark the text
| not-editable to prevent the user messing it up. IMHO, with care, we
| can make strings parseable and readable. - use the string as a key
| to a cache dictionary of "hidden" objects. This exists in vestigal
| form already. - wxStyledTextControl markers, which can be
| invisible, again as keys to a cache dictionary.
|
|> # - this should not be a physical replacement for the edit #
|> area, just a logical one where people want to use it ! #   IOW we
|> will keep gmEditArea around as it IS a good design !
|
| I hope SOAP2 to be a complete superset of cEditArea functionality,
| I don't want it to co-exist as IM[and Richard's]HO, consistency of
| GUI appearance and behaviour is important.
|
|
| Ian
|
|
| ----------------------------------------------------------------------
|
|
| _______________________________________________ Gnumed-devel
| mailing list address@hidden
| http://lists.gnu.org/mailman/listinfo/gnumed-devel


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBkROV5BCD+/pQ4WIRAu82AJ93UtkDD+taJpEjXGS0KIR2WHQUBgCgjZJd
D5Q9+R6e0+goYVjiM6XMO5w=
=f0XJ
-----END PGP SIGNATURE-----