[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] emr browser speedup
From: |
Karsten Hilbert |
Subject: |
[Gnumed-devel] emr browser speedup |
Date: |
Sat, 27 May 2006 15:01:45 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
Hi Syan,
I am reviewing your work on this. Thanks for your input.
Just a heads-up: For one thing I believe the current EMR
browser database access code is crap. Works, but crap,
conceptually. I thought differently before, when Carlos
first implemented it, mainly because I didn't have the
experience/confidence to believe differently. The reason we
made the browser operate on actual class instances was that
there was a vague idea of in-tree editing of data. Really
in-line, down to the item. While this isn't out of the
question entirely I do believe now that the browser should
(pretty much) do just that - browse. Editing individual
items below the encounter/episode level should really be
done by launching/switching to/displaying an appropriate/
dedicated/suitable item editor - *from* the tree, of course.
Anyways, what I'm trying to say, the EMR browser data
retrieval code should perhaps rather operate on simple dicts
which the middleware delivers from the database. Part of
which (sub-encounter/sub-episode data) should probably be
piped through Cheetah to get some nicely formatted HTML
(template user selectable) to be displayed on the right hand
pane. The tree should be filled with data lazily on
expansion, IOW dynamically with regard to what is actually
on screen.
Notwithstanding all that, your experimenting/implementing
multithreaded pre-filling of the EMR cache is definitely
worth exploring because we will want to do that even with
the above "text-only" scenario !
I'd suggest applying the above technique to 0.3/0.4 while
incorporating your current work into 0.2.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- [Gnumed-devel] emr browser speedup,
Karsten Hilbert <=