Re: [Gnumed-devel] forms concept (instead of placeholders)

[Karsten Hilbert]

On Wed, Oct 21, 2009 at 01:06:46AM +0200, Jerzy Luszawski wrote:

> > I am currently integrating your approach into GNUmed.
> I'm happy to hear this :)
> >
> > I am not really fond of adding non-generic fields to the
> > paperwork_templates table. 
> I don't get what you mean by "non-generic"?

Fields which won't apply to all (currently conceivable)
types of paperwork templates. It just so happens that yours
work with SQL queries directly (which is fine) but that's
just an implementation detail. paperwork_templates is
intended to store metadata *about* the templates, not
details of the handling of any specific template itself
(apart from which engine to hand the template to, I do admit
this half-shortcut ;-)

> > However, you do need a place to 
> > store the SQL query. I've been thinking why don't we make
> > the SQL part of the template XML itself ?  We could then
> >
> >     a) manage the query right inside the XSLT template
> >     b) extract the query from the retrieved template
> I think it will complicate things. 

It sure does but only a little. It gains the advantage of
not burdening the paperwork_template table with columns
specific only to this way of doing XSLT-forms.

> Now the template file contains only formatting. I see no advantage of mixing 
> formatting with other data.

I am not thinking of mixing but rather of combined storage
but I do see your point.

> It is easier to get the SQL from the table in database than extract if after 
> parsing the template. 

Not that I can see.

> The user can easily adjust the format (or 
> translate the template), without touching anything.

This would AFAICT only be an advantage if the templates were
files easily accessible from the desktop of the user.

> It can be used independently from formatting (eg. for export).

It can still. The separation of sql query and xslt template
would happen inside a dedicated, say, "get_xslt_template"
function returning a tuple (sql, xslt). Any other programmer
never needs to worry about it unless she wants to.

> Its alteration may be restricted to admins to avoid malicious code.

You mean that GNUmed will gain some protection from
malicious users putting rogue SQL queries inside templates
using them as attack vectors ? Indeed, that's a point. If
the SQL were objects managed entirely separate from the
templates using them that would hold true. That would,
however, be half a step back into the direction of having
"entirely safe" *builtin* placeholders as we do now.

So you want the "active" part of the code both be user
definable and safe. Hm. I think this may not be possible.
However, I don't have a problem with adding a table

create table ref.placeholder_defs
        pk serial primary key
        placeholder text                                -- this would be, say, 
"lastname"
        type text                                               -- this would 
be, say, "sql"
        action text                                             -- this would 
be, say, "select lastnames from dem.v_basic_person ..."

such that forms could use the placeholder "lastname" and
GNUmed would look up what to do about it.

> It does not break any internal database constrains.

But it's a non-generic column in a generic table and thus
breaks normalization. Don't worry you wouldn't really have
to think to much about all this because it'd get implemented
in the middleware once and be done with it.

> > Jerzy, can you supply an XSLT template that you have in use ?
> Here you are (there are Polish fixed text headings, but the structure is in 
> English):
> https://www.xythosondemand.com/home/BLZ/Users/jerzy.luszawski/Public/gnumed/application/print.episode.all%20progress%20notes.pl_PL.1-1.xsl
> https://www.xythosondemand.com/home/BLZ/Users/jerzy.luszawski/Public/gnumed/application/print.encounter.in%20clinic%20-%20visit.consultation.pl_PL.1-2.xsl

OK, I will have a look.

> > Could you make a suggestion as to how to store the query in
> > the template ? (as in which XML tag etc)
> Perhaps
> <xsl:param name="sql_query" select="SELECT ..."/>

I would be perfectly fine with this approach as well (it is
a lot less code to write) if that's fine for you. I just
asked because I have a lot less experience than you with how
xslt works :)

And I'm glad I asked because you've got good arguments such
as the malicious SQL one.

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