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 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
