[Top][All Lists]
[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