[Top][All Lists]

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

Re: [Gnumed-devel] GNUmed web interface

From: Tim Churches
Subject: Re: [Gnumed-devel] GNUmed web interface
Date: Thu, 15 Feb 2007 09:52:24 +1100
User-agent: Thunderbird (Windows/20061207)

syan tan wrote:
> mod_python is fairly simple, and it seemed to be the easiest to learn. 
> Much of the styling can be outsourced to css files I'm assuming, but 
> some things would require a rewrite ( for instance, the use of frameset 
> for the multiple panel idiom , the easiest ("hack") was to use a
> frameset from the initial login page, with other frames sized minimally,
> and then to resize them as required with javascript, prior to jumping
> with  &lt a href='' onclick="javascript:.." ; this most probably is
> present in the frameworks , but seemed more easily done with 
> basic html / javascript api , and cut and paste as each use case 
> is done.  I'm assuming the frameworks would make the cut and paste part
> less needed, but mod_python seemed to give the right amount of
> needed minimal function, like a session store and configurable 
> debugging output. 

My advice is don't lock yourself into mod_python. By all means use it as
a hosting alternative, along with FastCGI, plain CGI, native Python HTTP
server etc. Production experience with mod_python has been variable, and
the idea of running your app in the same process as the httpd server is
not comforting. Many now use FastCGI. WSGI is a generic Python Web app
interface designed to provide a standard API for all these lower-level
hosting facilities - chose a framework taht supports it (also, Albatross
does not but provides its own hosting abstraction, which predates WSGI).

A framework will (or should) provide a lot more on top of session
management (which is a bit lightweight in mod_python), like templating,
I18n and l10n support etc etc, as well as support for MVC or other
logic-presentation separation (otherwise just use PHP...).

Oh, and don't even consider Zope. It is good as a content management
system but a quagmire for more general purpose web app development.
Django also has a content management system bias (or roots), although it
is definitely good for other things. Turbogears is good for the lot, as
are teh various lower-level frameworks such as CherryPy and Pylons etc.

Check out the blog of Ian Bicking as a start:

Tim C

> On Thu, 2007-02-15 at 07:32 +1100, Tim Churches wrote:
>> Sebastian Hilbert wrote:
>>> Hi ,
>>> Thanks to some source code I have been sent by Syan I have been able to 
>>> test 
>>> what we have always proclaimed. It is possible to use our business objects 
>>> such as gmLog, gmPG2 and so on from a web interface.
>>> Although I cannot comment on how well it works or if it is an ugly hack or 
>>> not 
>>> I can tell it is possible to use a webinterface and a number of rich 
>>> clients 
>>> at the same time.
>>> Since a web client is yet another client to design and maintain I wonder if 
>>> it 
>>> makes any sense to borrow html from other webbased open source emr 
>>> applications.
>>> Can anyone comment on where webframeworks such as django or turbogears 
>>> touch 
>>> this subject ?
>> The thing about the latest Web app development environments is that they
>> tend to assume that you will do things their way, which includes using
>> their object-relational SQL mapping layers etc. Not sure how well that
>> plays with the GNUmed business objects, but I suspect it may be
>> problematic as they are both doing similar things. However, of Django
>> and Turbogears, the latter seems to be the more modular.
>> However, there are many other more lightweight Web app frameworks for
>> Python, including the ones used in Django and Turbogears eg CherryPy.
>> Pylons is also good, I hear. In NetEpi, we have used Albatross (see
>> ), which predates most of these but has
>> stood the test of time rather well. It helps that our lead NetEpi
>> developer is also the maintainer for albatross, and its original author
>> is a colleague. However, it is beginning to creak a bit at the seams,
>> and a more recent Web framework might be a better choice.  Perhaps the
>> GNUmed business logic can be grafted into Turbogears?
>> Tim C
>> _______________________________________________
>> Gnumed-devel mailing list
>> address@hidden
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden

reply via email to

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