[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] abstracting templates for letters

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] abstracting templates for letters
Date: Sun, 03 Aug 2008 01:05:41 +0200

> Reading brought me
> to ref.paperwork_templates table which I briefly inspected with pgadmin3
> tool (I'm still totally new with Postgres and its tools...) where I've
> found out the following:
> COMMENT ON COLUMN ref.paperwork_templates.engine IS 'the business layer
> forms engine used
>        to process this form, currently:
>        - T: plain text
>        - L: LaTeX
>        - H: Health Layer 7
>        - O: OpenOffice';
This should really be: "currently: OpenOffice" as we currently don't support 
any other engine.

> afaik, only OpenOffice is mentioned as the tool for writing letters
> based on templates, right?

> I'm thinking about the possibility to abstract this mechanism
This is already abstracted. That's the whole reason for the .engine field in 
the first place.

> However, I'd prefer to be free whether to attach *.odt, *.pdf or
> e.g. *.md (markdown) version of the letter in the patient's archive
> tree
You can even today. GNUmed just doesn't currently support accessing other
engines for letter *creation*.

> - i.e. I'd leave the present capability to automatically load OO &
> add the *.odt to the archive tree as user-option and therefore providing
> more general mechanism so that users can add their own application which
> they want to use for writing letters based on templates.
It's a bunch of code that needs writing.

> In short, my idea is to provide some 'general' mechanism or protocol (if
> possible) for sending template-data to external applications instead of
> hard-wiring needs of specific applications
There is no hard-wiring in GNUmed letter writing (well, the OOo engine is 
hardwired to access
OOo but that's a tautology).

> Don't ask me about the details - I even dunno whether it's possible in
> how much refactoring it would involve.
It is certainly possible and it won't need too much refactoring (likely some, 
as always). It
just needs engine code to get written.

> However, it looks I'd have to make my hands dirty with some Python,
That would help a lot in getting things done faster.

> although the choice of using Simple Invoices and CMS Made Simple would
> require some PHP as well :-)

Psssst! Schon das coole Video vom GMX MultiMessenger gesehen?
Der Eine für Alle:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]