gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Open Office templates


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Open Office templates
Date: Mon, 1 Sep 2008 11:59:42 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Jerzy,

> > However, the placeholder handler requests the data it needs
> > from other parts of the client which may or may not include
> > interacting with the user.
> I meant making a list of placeholders available to front-end before
> opening a template.

I understood as much.

> Then feed the all data at once to the parser (when
> opening a template), which would only replace fields with values
> without need to fetch values from backend or user or other modules of
> GUI. 

I am not sure I see too much of a significant difference between the two
approaches:

1) currently:

- create template

... time passes ...

- load template
- parse template
  - find placeholder
  - retrieve data for placeholder
    - may involve user interaction
  - insert data for placeholder
- open template in OOo

2) proposed

- create template
- create list of placeholders for template

... time passes ...

- load template
- load placeholder list
- retrieve data for placeholders in list
  - may involve user interaction
- parse template
  - find placeholder
  - insert data for placeholder
- open template in OOo

A potential combined approach could be:

- create template

... time passes ...

- load template
- create list of placeholders from template
- retrieve data for placeholders in list
  - may involve user interaction
- parse template
  - find placeholder
  - insert data for placeholder
- open template in OOo

But frankly I am not sure I see the benefit ? In fact, it
would involve parsing the template twice instead of once.

> This would make template handling independent of calling module.
Can you elaborate on the benefit ?

> The calling module has all context information available (current patient, 
> encounter, etc.) and IMHO it is
> easier and far more efficient to pass data as a parameter to the
> parser,
But there is no net gain in efficient because the data needs
to be gotten at some stage anyhow.

> than to teach a parser where to look for data.
Now, of course, the OOo-specific replace code itself has no
knowledge of how and where to get data values from:

        gmForms.py::cOOoLetter.replace_placeholders()

This method is passed a placeholder replacement handler from, say, here:

        gmFormWidgets.py::create_new_letter()

If you look what the handler is you find this:

        gmMacro.py::gmPlaceholderHandler

which in turn has no idea of

- whether it is invoked from a template or something else
- which template that would be
- let alone which engine this template is processed by

All this is nicely abstracted away. The template/engine
specific code gets passed a handler and all it does it to
ask the handler to give it values. It doesn't even know how
and where the handler gets the values from. The handler,
again, has no idea whether the values it returns are spoken
out, thrown away, or replaced into whatever sorts of
placeholders a templating engine might care to support.

It doesn't seem to make the slightest difference at what
time in the processing chain the values are actually
retrieved.

However, there IS a downside the retrieving values in a
single scoop and passing them to the replace code:

You need to store ALL the data in memory at once while the
retrieve-replace-throw_away approach only needs to consume
as much memory as is required for the placeholder data
currently processed.

> OK, maybe I looked at it from different point of view. I
> presumed all templates would be created by system
> maintainer, who will have no problem creating corresponding
> SQL query and provide placeholder list. If end-user creates
> a template he/she must not be bothered with backend access. 
That is the rub.

> But there must be a way to pass parameters to the paser. It's silly to
> ask user which encounter he wants to print, when he has this encounter
> already displayed.
How do you know which encounter the user wants printed ?

Disregarding the fact that it is silly to ask for which
encounter as encounters are an ordering principle rather
than data by themselves - have you never written a letter
which included data from several encounters ?

The user will - if the template asks for it - be presented
with a list of narrative data from several encounters in
order to select which narrative to include into the letter.

BTW, there IS one technical drawback to using text field
placeholders over plain inline placeholders: text fields do
not inherit text attributes from their "surrounding" text
while inline does.

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




reply via email to

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