gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] GNUmed web interface - technologies


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] GNUmed web interface - technologies
Date: Mon, 12 Jul 2010 07:22:04 +0200
User-agent: KMail/1.13.3 (Linux/2.6.33-6-desktop; KDE/4.4.5; i686; ; )

Am Sonntag 11 Juli 2010, 23:21:09 schrieb Dave Cramer:
> On Sun, Jul 11, 2010 at 12:37 PM, Sebastian Hilbert
> 
> <address@hidden> wrote:
> > Am Sonntag 11 Juli 2010, 17:53:34 schrieb Jim Busser:
> >> On 2010-07-11, at 5:36 AM, Dave Cramer wrote:
> >> > If you are indeed serious about keeping both clients web, and thick
> >> > then I would think that both of them would have to access the data
> >> > through some middleware in order to maintain data integrity and keep
> >> > one codebase.
> >> 
> >> Sounds like the ability of *both* clients to access the *same*
> >> middleware would be useful. Is there an alternative?
> >> 
> >> It seems to me there are two modes of interacting with patients'
> >> records... one patient at a time, and multiple patients at a time.
> >> 
> >> There are also two modes of using clients... any one praxis (medical
> >> practice) could resolve to standardize on a single client, or it could
> >> decide to allow more than one client (web, thick client).
> >> 
> >> Supposing a praxis decided it wanted to allow both, would it be possible
> >> to contextualize the postgres GNUmed databases, with respect to
> >> permitting or disallowing concurrent record access?
> >> 
> >> It seems to me that, provided a user is only allowed to work on one
> >> patient's (or one user's) records at a time then the danger of two users
> >> using two different clients that did not know about each other could be
> >> managed through controls that postgres might offer on the tables and
> >> records themselves? Sorry if it is either magical thinking, or
> >> theoretically workable but unsupported... <g>
> > 
> > I am no expert on this. I currently fail to see the problem. How is using
> > two GNUmed wxpython instances talking to the database through gmPG2 and
> > friends different from one GNUmed wxypython instance and one web
> > instance ?
> 
> The question was whether or not to use some server side web framework.
> Django to be specific.
> 

Ah. Sorry. Yes I have learned along the way the about ORM. This would 
effectively mean to bypass the GNUmed middleware which I did not consider 
anyway. And I guess if one does not use ORM of django then django does not 
need to be used at all.

> While I haven't used it specifically, I would imagine it has some form
> of ORM in it. This is what I see as being problematic. It would not be
> using gmPG2.
> 
> > As far as I am concerned we are *not*  bypassing the GNUmed middlware. We
> > log in through the existing middlware and we get and store data through
> > the existing middleware ( I hope this can be done).
> 
> I'm sure it can be done. just not as easily as say using django as the
> backend.
> 
Now I got it.

> > This might not be the best of breed approach as far as web applications
> > work these days but unless it shows major slowness or complicated code
> > choices to make I thing there is no problem.
> > 
> > One thing I still not fully comprehend is the asynchronous parts of a web
> > interface. But I have been told that AJAX can also be synchronous. I
> > currently have not enough knowledge on that part.
> 
> Yes, it can be synchronous. google "comet" To be honest synchronicity
> should not be an issue within a local area network. IE within a praxis
> ( I hope I'm using that work properly)
> 
Good to know.

Sebastian



reply via email to

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