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

[Sebastian Hilbert]

Am Samstag 03 Oktober 2009 21:22:26 schrieb Jerzy Luszawski:
> Hello,
> 

> I continue to develop my branch of gnumed, and seeing the latest posts
>  about placeholders, I decided to share my concept of generating all kind
>  of printouts.
>
Great. Thanks for the effort. Karsten is away for a week but will be happy to 
comment when he returns.

 
> 1. My needs:
>       - all data from backend should be available to a form, so no fixed list 
> of
>  placeholders is acceptable - a form may contain data from unknown number
>  of records (1 or more) - a form should be editable after creation
>       - a form with data need NOT be stored in backend after creation
> 
> 2. Using OpenOffice Writer with Python bridge did not work for me
> 
Are you on Linux or on Windows ? Pyuno seems to give trouble on Windows.

> 3. Currently the best option IMHO is preparing data for a form in XML
>  format, then process it with XSLT template to get a HTML file. This file
>  is easily loaded into OO Writer or displayed in browser. so it can be
>  previewed, edited and printed out. The XML can also be exported to another
>  application if needed. This may be a common path for many uses.
> 
> 4. The key for implementation is the decission to fetch data for the
>  template directly from backend using SQL query. This query is stored
>  together with template (a new field in ref.paperwork_templates is
>  required, I added 'sql_query'::text). It may have parameters just like any
>  other query executed via gmPG2.run_ro_queries.  It returns all data at
>  once, no need to collect data from multiple objects. Now just few easy
>  steps are required:
>       get the template
>       fetch data (== execute the sql query with supplied parameters), making
>  valid XML document from them apply XSLT from template
>       display/print/whatever
> 
> 5. The nice thing about postgresql is that it can output a table in XML
>  format (see query_to_xml function). Using it I can avoid the problem of
>  characters that need to be escaped in XML. The drawback is the ugly look
>  with many quotes, which may be confusing.
> 
> 6. I enclose in the attached file the class cFormXSLT I use for this
>  processing. The typical invocation is like this:
> -----------------
>       #get a template object
>       template =
>  cFormTemplate(aPK_obj=get_paperwork_template_pk(template_type=print_all_pr
> ogress_notes)) #get a form object based on this template
>       _report = cFormXSLT(template)
>       #process it: fetch data, apply stylesheet
>       #parameters are prepared like for any gmPG2.run_ro_queries
>       _report.process(sql_parameters = {'pkeys':
>  self.__curr_node_data['pk_episode']})        #you can pass more pkeys if you 
> need
>  #display (I always preview the reports in OO Writer)
>       _report.preview()
> -----------------
> 
> 7. This approach is the most flexible and does not need any changes in
>  application code to get a form. You can make single or multi-row
>  templates. You have the possibility to use CSS or other formatting. An
>  example SQL queries are here:
> https://www.xythosondemand.com/home/BLZ/Users/jerzy.luszawski/Public/gnumed
> /application/update.paperwork_templates.sql_query.sql
> 
> An example XSL template:
> https://www.xythosondemand.com/home/BLZ/Users/jerzy.luszawski/Public/gnumed
> /application/print.episode.all%20progress%20notes.pl_PL.1-1.xsl
> 
> To resolve problem of text fields with multiple paragraphs (hard line
>  breaks) I filter these fields through a function 'xml_paragraphs', then
>  add corresponding template in XSLT. The function is here:
>  https://www.xythosondemand.com/home/BLZ/Users/jerzy.luszawski/Public/gnume
> d/application/function_xml_paragraphs.sql
> 
> 8. Enjoy. Comments and improvements welcomed ;-)
> 
This is really exiting news and I sure hope you and Karsten can find a way to 
merge your feature back into the main trunk. I hope the concepts are not 
orthogonal. that way a lot more users could benefit from your great work and 
you could benefit from bugfixes in other areas of GNUmed.

Can anyone comment if this situation would warrant switching to SVN, GIT or 
the like ?

Sebastian