Re: [Gnumed-devel] yet another templating engine

[Sebastian Hilbert]

On Thursday 10 November 2005 01:22, address@hidden wrote:

Just to throw in one more package. I have used it in productive environments.
No idea how it compares or if it even applies to GNUmed but nevertheless it 
works.

http://www.reportlab.com/rml_index.html

Sebastian

> 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
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel

-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://address@hidden
My OS: Suse Linux. Geek by Nature, Linux by Choice