[EMAIL PROTECTED] wrote: > Quoting Tim Churches <[EMAIL PROTECTED]>: > > >>These object-relational mappers (ORM) don't HAVE to use teh lowest common >>denominator. For example, the ORM in NetEpi CaseMgr is targetted at >>PostgreSQL and makes use of POStgreSQL transactions to help ensure data >>integrity. > > It's mainly postgres inheritance that we would miss, also server-side > triggers and views. Inheritance you could model in an ORM, but > the others would get tricky.
Why can't triggers and views be implemented in the middelware business objects layer, instead of in the back-end? > Of course, you don't need them if you keep the backend to static > data storage and put all the business logic in the client. Yeah, that's the idea. > gnumed was originally concieved as "smart-server, dumb-client" > model, with backend triggers doing all kinds of high-level stuff, like > interactions checking. I am now convinced that this is arse-about, putting the back-end cart before the horse, as it were. Better to put all the smarts in one layer, the middleware, and use database back-ends in a dumb fashion, and thin-client Web interfaces (so the interface smarts are very closely integrated with the business logic in teh same set of classes in the middleware layer, which all runs on the server). > We strayed away from this and IMHO that's > (partially) why things got messy, the client is too smart > and complex for it's own good. > > >>>It means a usable web-based EHR is now on the horizon, although I'm >>>not sure we've arrived yet. >> >>I think that to do a good Web-based EHR, > > OK, so my above these points are academic in a Web-based model as the > database 'client' is on the server anyway. Yup. The whole application is made of instances of classes which know how to both store themselves in the database back-end, but also how to display themselves via the Web front-end, and how to relate to or use other instances of the same or other classes. >>we need to write down the >>requirements, distill the lessons learnt from GNUmed, MD2 etc etc, pick the >>best toolset (probably Python, PostGreSQL and various Python libraries for >>doing AJAX-enabled Web apps) but otherwise start with a clean sheet of paper. >>Trying to adapt GNUmed, VistA or anything else may be more trouble than it is >>worth. > > Web is always tempting, but we need to be honest in our motives: it's > a shitload easier to develop and deploy, but we need to look closely > to see if web can meet our non-structural requirements, particularly > high data-entry speed and mouseless navigation, personally I'm still > somewhat sceptical. I still think that Web apps are slightly harder to develop, but yes, much easier to deploy. A Web app running from a Web server on the LAN can be very, very fast. But yes, careful attention needs to be paid to data entry ergonomics - but it is doable, I hope, although it does involve Javascript, alas. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
