gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] cheetah module


From: ihaywood
Subject: Re: [Gnumed-devel] cheetah module
Date: Thu, 10 Nov 2005 08:22:13 +0800
User-agent: Internet Messaging Program (IMP) 3.2.1

Quoting Karsten Hilbert <address@hidden>:

> On Tue, Nov 08, 2005 at 08:20:59AM +1100, Ian Haywood wrote:
> 
> > > I recommend to change 
> > > GNUmed in a way so absence of Cheetah will be non fatal.
> Well, since Cheetah is available in Debian and anyone can
> (have) install(ed) Debian for very nearly free I don't see
> that big of a problem.
> 
> > > 1.)http://prdownloads.sourceforge.net/cheetahtemplate/
> I'll have a good look tomorrow what this will buy us. Ian,
> can you sum up in a few words exactly how you plan to use
> Cheetah - what advantages does it bring in ?
> 
> If I understand things correctly it is a parser for
> templates so it would replace our custom "engines". We'd
> still need to write the templates ourselves (of course).
> Which seems to make the claim "Cheetah supports any text
> format" an obvious, moot point. 
Most templating engines are built around the assumption of SGML

> Which can just as easily be done with stock Python string
> replacement (%s stuff). The one point I can see is that it
> seems to allow adding *logic* into the template - am I right
> there ?
Yes, sort of. Cheetah offers more features than simple string
substitution, without the risks/problems of embedding python into templates.
In particular, it can access "sub-fields" which can in reality by 
methods/attributes of our clinical objects: this allows us to shift logic
out of scripts and into the clinical layer as appropriate.
Of course we could implement this ourselves too fairly easily, and if using
cheetah causes real problems I'm happy to do that.
 
> So, can you give a practical example of how we would use
> Cheetah and what we would gain from it over stock Python.

#if $letter.include_phx
  \begin{tabular}
  #for i in $clinical.get_past_history
    $i.name & $i.start_date \\ % this better separates logic/display issues 
    % than my current solution, which is passing in a 2D array (forcing the 
    % business leyer to get involved in how tables are displayed)
  #end
#end


#for i in drugs
  $i.name \\
  \hspace{1cm} $i.preparation \\ % this is how we want to print it: not a table
  \hspace{1cm} $i.instructions \\
#end


Ian




reply via email to

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