Re: [Gnumed-devel] Open Office templates

[Karsten Hilbert]

On Mon, Sep 01, 2008 at 11:52:26AM +0200, Jerzy Luszawski wrote:

> > 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
> That's what I want to avoid. My assumption (based on my own experience,
> hence the unavoidable bias) is that user most of the time wants to print
> what is already displayed. So, there is no need to ask him anything when
> he hits "print" button.

Well, if you want to create a template which does not
require user interaction simply use placeholders which do
not require user interaction (those placeholders may need to
be created, lo and behold).

Such a placeholder might then be named "current_soap_all" if
the intent is to retrieve ALL the SOAP rows for the current
encounter w/o bothering the user.

That placeholder does not have any business with the
existing placeholder "soap_s" which retrieves SOAP rows of
type "S" and lets the user select which to include.

> > - 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.
> Why twice? You parse it and get the replacement data straight from the
> retrieved list.

1) parse the template to find list of needed placeholders
   - can be done once at template modification time
2) parse the template to replace placeholders with actual data

I don't think you are suggesting to simply retrieve all data
for all possible placeholders and pass that to the
placeholder replacement code ?

That'd be rather impossible as the placeholders can be of
arbitrary complexity (and thus data size).

> > 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.
> I strongly disagree with this. 
> 1. Memory is fast (and cheap). Network connection is extremely slow
> compared to memory access.

While true, memory isn't unlimited as opposed to disk size.

> 2. Making a query to DB takes so much resources, than it is even hard to
> compare with storing a variable (or list of variables) in memory.

Have you benchmarked your assumption that it does make any
difference ? I cannot observe a difference in practice. Of
course, the placholder data provider caches values (at least
for one session of replacement).

> 3. If data are already displayed there in no need to query DB at all,
> just pass the data as parameters. Saves lots of processing time both in
> client and server.

You are assuming that data display and data representation
are the same. Secondly you are assuming that what is on
screen is suitably formatted for printout. This may happen
but only by coincidence. If so simply press PrintScreen.
Thirdly you are violating the programming principle "Single
Source Of Truth".

The display code does not keep track of data. It simply
displays what it is told to display by the controller code.
This is the Model-View-Controller concept (which isn't
purely implemented in GNUmed but close enough for now).

If you want to create a printout you need to go to the
controller (= model) code which retrieves data from the
Single Point of Truth, the databae, unless it finds some of
the data in its cache.

> 4. DB engine performs better when processing one query returning all
> necessary data, than several queries returning partial results.

True. That is why we have clin.v_emr_journal formatting data
for journal display, for example.

> When you
> make these multiple queries executed in separate batches the performance
> is even poorer.

Performance does drop due to multiple queries. Query time is
dwarfed by connect time, however. Have you benchmarked your
assumption of slowness ?

I fear you are violating the

First Principle of Optimization: Don't.

> I'm not sure: what happens when the same placeholder is used many times
> in the template?
It is cached. At least that's the intent - this area needs a
bit of work.

> When server is fast and there are only few clients, you may not notice
> it, but when number of clients grows, the impact will become noticeable.

Absolutely. But GNUmed is not intended to be used by clinics
with, say, more than 30 clients running at full speed
simultaneously. The usual use case would rather be 3-5
clients.

> ***
> Creating letters from data chosen by user from a list of possibilities,
> or creating serial correspondence is different matter.
We are not even talking about serial correspondence yet.

> I just need to
> make a nicely formatted report of displayed data,
Your error in thinking is that the display code somehow
knows what it displays. That is not the case. It simply
displays bytes handed to it. It doesn't have the faintest
idea of how to reformat what is displayed so it is suitable
for printing. If what is displayed is directly suitable for
printing simply print a screenshot - taking of which GNUmed
actually has builtin support for those poor OS' which don't
come with that support built into them.

> and plain text from
> EMR journal is not enough. I try to use OO for this and to make it as
> simple as possible.

Now, that's a valid and concrete use case. If you elaborate
on what you want to achieve we can think about ways of
getting it done :-)

Mind you, there may (and will) be changes needed by all the
code discussed here but we need to be exactly clear what
needs to be changed how and why. Or else the next use case
will just throw things over again.

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