Re: [Gnumed-devel] re Medication List template

[Karsten Hilbert]

A few words of explanation. The basic fallacy with the
medication list printout is this:

1) for maximum efficiency quite a bit of computation needs
   to be applied for sorting / formatting drugs and their
   informational parts

2) one would like to be able to have the capacity to drop in
   a replacement formatting "template" for which the template
   better be as decoupled from the client as possible - which
   we achieve be the "placeholder" API

3) templates, however, cannot compute much of anything - unless
   written in a computational template language such as TeX
   (which would then be *quite* involved) or Cheetah (which
   we haven't considered sufficiently yet)

Thus it seems logical to do the computation inside the
client code. But this requires the client code to know about
the target template language !

There is a few ways to alleviate the problem:

1) make placeholders somewhat intelligent

        We do this by allowing for formatting/selection to be
        defined inside the placeholder, eg. $<today>$ can
        include how to format the date: $<today:%Y-%m-%d>$.

        This is how we currently handle current meds:

        $<current_meds::put %(brand)s of %(substance)s with %(strength)s here>$

        IOW, we include a string replacement template with the
        placeholder !  This way, the LaTeX definition of the
        table line sits inside the placeholder and gets
        substituted into by GNUmed. The then-valid LaTeX code is
        put back into the template. Et voila.

        This concept only goes so far, however. Due to the
        line-based nature of template processing extending this
        concept to Rogerio's recently contributed (very useful)
        medication list template would mean we'd have to define
        several placeholders along the lines (slightly
        exaggerated):

                curr_meds_wakeup
                curr_meds_after_breakfast
                curr_meds_before_lunch
                curr_meds_after_lunch
                curr_meds_before_supper
                curr_meds_after_supper
                curr_meds_bedtime
                curr_meds_at_other_times

        which also only works if the schedule entered into
        GNUmed actually turns out computable.

2) use a computationally enabled templating language

        Cheetah and TeX allow for first defining data and then
        generically reusing that data in the template. Thus,
        current meds could be TeX-defined and then used in the
        template (same with Cheetah). I currently don't know how
        to do so, however.

3) teach GNUmed to directly generate complete bits of target
   formats

        This could range form generating complete LaTeX
        documents to computationally complete LaTeX "sections"
        which then replace something like $<current_meds>$.

        GNUmed would then need to know what sort of target
        format to generate.

        It would allow us to do formatting/selection etc in code
        inside GNUmed but would also limit us to the currently
        available range of target formats (IOW, if 0.6 only
        implemented LaTeX Rogerio couldn't use it in his .odt
        template).

        This may actually make sense for such specific and
        important things like medication lists. It seems to
        strike a good balance.

Currently we do 1). Shall we go with 3) ?

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