On Thursday 10 November 2005 01:22, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>: > > 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 > [email protected] > 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://[EMAIL PROTECTED] My OS: Suse Linux. Geek by Nature, Linux by Choice _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
