> We've been spending the better part of the last 4 years to > do the following so welcome back to Ground Zero: > > > So I started to rewrite the system, this time I wanted to do it properly, > > and > > using a non-proprietary backend schema. > ... > > I want to clean that up and document it properly before I bother people > > with > > it. > > > In principle, the architecture looks like that: > > > > a) every database concept (like "a patient", "a doctor", "an address" etc.) > > is > > wrapped into a gmdbXXX class with standardized high level accessor methods. > > They all inherit common traits from a gmdbObject ancestor including a very > > simple and crude caching mechanism. There should be no SQL queries at all > > in > > the GUI code > Hm, this sounds suspiciously like gnumed/client/business/*.py > > I have to admit I haven't yet been able to see through the > caching mechanism. I am sure keen on learning whether it > provides benefits over what we use in GNUmed. > > > b) every possibly self-contained functionality (e.g. "prescribing", > > "appointment booking") exists as an independent module which can be run > > either standalone or as a plugin within the gnumed framework > While nice and having been tried I have found it to be hard > to maintain. Likely our GNUmed code isn't clean enough yet. > Once you get to a certain complexity of functionality there > are assumptions in the code that are met by the framework > which isn't available when running standalone ... > > > c) all such independent modules ( regardless whether gui or not) > > communicate > > with each other exclusively via the central messaging hub (dispatcher) > Likely we have taken a few corners here that prevent us from > running plugins standalone. > > > d) as a rule, GUI components are designed with wxGlade. The generated GUI > > code > > is never modified manually, but a wxXXX module inherits from the generated > > wxglXXX module. > How does this allow for creating widgets from non-wx-Core > GUI classes ? Say I wrote a dedicated progress note > notebook, how can I use it in wxGlade ? > > > f) Not only for simplicity, but also for speed reason, the backend schema > > is > > not always normalized. > Does it properly support clinical encounters and episodes > of care ? > > > At times, where it would yield a substantial > > performance gain, foreign keys *may* be the data itself > "would" or "does" as in "tested" ? I doubt it'll make much of > a difference in most cases. Or so the PostgreSQL people > attest to. > > > g) the backend schema is versioned. Modules check what backend version they > > need. The backend is updatable incrementally - after the first full version > > number, only "update" schema sql snippets will be generated, allowing > > update > > of a running system without anybody having to log out first > Same as GNUmed. > > > h) installation should be running "gnumed.sh" and "python setup.py install" > > and nothing else, no hoops to jump through for the end user. This requires > > an > > administrator running gnumed.sh as somebody who has the right of creating > > new > > postgres databases and users > Yup, that is doable with GNUmed as it exists now. Do you > intend to store program bitmaps (icons) in the database > generated from python encoded inline data ? Or else how do > you intend to make "python setup.py install" install bitmaps, > docs etc in a client system ? > > Trust me, been there, done that. > > 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
