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

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]