Answered in my last post??? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Churches Sent: Friday, 30 December 2005 10:54 AM To: [EMAIL PROTECTED] Cc: General Practice Computing Group Talk Subject: Re: Re: [GPCG_TALK] The Dreaming
[EMAIL PROTECTED] wrote: > > Quoting Tim Churches <[EMAIL PROTECTED]>: > > > David Guest wrote: > > > [EMAIL PROTECTED] wrote: > > > > > >>I agree. I have also been looking at Rails and it's python > equivalents, > > >>the breakthrough seems to be auto-generating SQL from Python/Ruby > template > > > > >>classes. > > >> > > > > > > Fan django? > > > http://www.djangoproject.com/ > > > > Not nearly as cool a name, but TurboGears may be an even better > > prospect, especially the forthcoming v0.90 release: > > http://www.turbogears.org/ > I agree this does look very appealing > Note this isn't inconsistent with still wanting a handwritten backend > (http://sqlobject.org/SQLObject.html#automatic-class-generation) > > SQLObject does allow arbitrary joins etc., which is good, but the code > looks > pretty ugly: > from sqlobject.sqlbuilder import LEFTJOINOn > MyTable.select( > join=LEFTJOINOn(Table1, Table2, > Table1.q.name == Table2.q.value)) > > I'm not sure this is any better than a backend view, (and slightly > slower.) > But I take Tim's point about putting all the logic in one layer in one > language. Yes, I think that it is possible to create better ORMs than SQLObject, for specific purposes. For NetEpi, we plan to extend our current custom ORM (which is PostgreSQL-specific and makes good use of the features provided by PostgreSQL, especially transactions and views, but not inheritance or triggers). Likewise, we plan to stick with Albatross as the Web framework/templating system, not CherryPy and Kid as used by TurboGears. But we do hope to leverage Mochikit, which is the Javascript used by Turbogears to provide AJAX capabailities and other browser-side tricks. > With Web interfaces, would it really fly? If the Web server is on the LAN within the practice, accessed via 100Mbit/s Fast Ethernet (or even 10Mbit/s Ethernet), and the Web apps runs as a persistent process on the server (without the old CGI set-up/tear-down-with-every-interaction overhead) then Web apps can be every bit as fast as a GUI. The same applies if the app is hosted on a remote server to which there is a fast, low-latency braodband connection. But you do need to make sure that the Internet connection will always be fast - and it is very difficult to ensure that. Otherwise there will always be occasional but annoying delays while some other person on the ISP network segment as you downloads a pirated movie or something. But a $1000 machine or two is all that is needed to run a Web/database server in each practice, and with Slony it is easy to automatically slave to an off-site back-up database somewhere, for continuous off-site back-up and instant recovery. > I'm addressing this to those running practices: if > it could be made fast enough with all the features like auto-completion > and a > WYSIWYG editor, is this something you would actually be prepared to use? There are several open source Javascript in-browser editors available, but I haven't investigated these to determine how good they are, or how hard it would be to make them support smart text wrangling eg on-the-fly auto-completion or mnemonic/abbreviation expansion. Otherwise browser-specific plug-ins or an embedded Java app might have to be used. But you can do hell of a lot with Javascript these days. > We don't want to end up like a certain other web-based EHR (nat-div > subscribers know want, or rather, who, I mean ;-) Huh? Which one? What? Prey do tell, it could be instructive. Don't mention names if you prefer, but give us the gist of it, the take-home message of what can go wrong or what not to do. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
