On Thu, Nov 10, 2005 at 08:22:13AM +0800, [EMAIL PROTECTED] 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
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
