gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] more guidelines for newbies


From: Horst Herb
Subject: [Gnumed-devel] more guidelines for newbies
Date: Sun, 7 Apr 2002 23:37:20 +1000

1.) strings and translation:

hardcoded error strings meant for developers / debugging are in English.
All other strings MUST be translateable, that is called as a gettext 
function. To achieve this, you do the following:

#import translation module
import gettext
#set an alias for the translation function
_ = gettext.gettext
#whenever you use a string, do it like
print _("this will be automatically translated")
#instead of
print "this can't be translated and should thus not be programmed this way"


2.) when doing database work, NEVER rely on a table being present in the 
"default" database. Lookup the appropriate service 
(as listed in http://gnumed.net/whitepapers/serviceslist.html) and use it 
accordingly - for example ALL person and address related details are 
available via the service "personalia" now.
Whether "personalia" is actually implemented in "default" or on some other 
server in a completely different database should not matter to client 
programmers. Just request the right service from the database broker 
object, and that's it - should work.
In order to make this testable, you must set up your configuration tables 
in the default database accordingly
(database name in "db", service in "distributed_db", reference to db and 
distributed_db in "config" attributes "db" and "ddb")

3.) When trying to map database results to widgets, remember that not all 
widgets can use the same functions (like SetValue()) under all 
circumstances to set their properties. Notable examples for exceptions are 
"choice boxes" and "combo boxes". It might be preferrable to have a 
function SetData(), UpdateData(), ClearData() for each dialog instead - 
far more control over what is actually happening to the widgets, though 
unfortunately a little bit more typing.

4.) and finally, try to always insert at least one line of docstring 
unless the function is no more than a couple of lines long and perfectly 
self-explanatory

Horst



reply via email to

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