[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 http://wiki.gnumed.de/bin/view/Gnumed/PatientLetters 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?
Correct.
> 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 :-)
Correct.
Karsten
--
Psssst! Schon das coole Video vom GMX MultiMessenger gesehen?
Der Eine für Alle: http://www.gmx.net/de/go/messenger03