gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] cheetah module


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] cheetah module
Date: Thu, 10 Nov 2005 20:01:51 +0100
User-agent: Mutt/1.5.9i

On Thu, Nov 10, 2005 at 08:22:13AM +0800, address@hidden wrote:

> > 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
Ah, OK.

Point 1) We want a convenient syntax in our templates.
Point 2) Cheetah provides that.

> 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:
Point 3, good.

> Of course we could implement this ourselves too fairly easily, and if using
> cheetah causes real problems I'm happy to do that.
We could but we don't need to that way.

> > So, can you give a practical example
> #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

Got it. Nice. From what I understand/see so far I think it's
OK to use. Let's go ahead and try.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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