PDF Reporting with OPAL

[Khchine Hamza]

Hi all,

I am wondering if OPAL framework itself has and support a PDF (and Excel ..) reporting engine or I should use any others django packages for PDF générating such weasyprint ?

Thanks

Hamza Khchine

[Fred Kingham]

Hey, there isn't anything like that at the moment I'm afraid. It sounds like something that one would want though.

I'd go for an existing pdf generator, but if you can make it generically reusable with OPAL then obviously that would be awesome.

Cheers,

 Fred

--
You received this message because you are subscribed to the Google Groups "OHC-OPAL" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohc-opal+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Miller]

Hi all,

I don't think there's an established Opal 'generate PDFs' option at the moment.

Optimising print layout/css so that a human doing print or print->save-as-pdf gets something sensible is something that definitely works, but it depends on what your users need obviously.

Every time I've ever implemented PDF-based report generation for e.g. non-Opal projects, it's been a massive pain to maintain...

A bit like fancy HTML emails!

The Django docs suggest using reportlab, which looks like it hooks quite nicely into Django views.

I think it depends a lot on how complicated your output document is going to be.

In general, when we have users who want PDF documents I encourage them to consider other options - although that's not always possible :)

We are planning to look more closely at generating data-centric reports in the next few months in a project for one of the hospitals we work with.

That should end up with:

- An interface for user-specified report formats e.g. which fields, columns etc for data extracts, producing a single merged csv file

- An API for programmer defined complex reports, which would enable things like fields which are the result of computations (end date - start date for instance)

We have some mockups of the extract interface and have had some very high level discussions about potential report APIs, but would be v. interested if you've seen particularly good report building APIs elsewhere for us to take a look at for inspiration. 

(I've only ever seen APIs I'm not keen on to be honest !)

Hope that helps !

David

On Mon, 13 Mar 2017 at 17:29 Fred Kingham <fred.k...@openhealthcare.org.uk> wrote:

Hey, there isn't anything like that at the moment I'm afraid. It sounds like something that one would want though.

I'd go for an existing pdf generator, but if you can make it generically reusable with OPAL then obviously that would be awesome.

Cheers,

 Fred

On 13 March 2017 at 16:06, Khchine Hamza <hamzak...@gmail.com> wrote:

Hi all,

I am wondering if OPAL framework itself has and support a PDF (and Excel ..) reporting engine or I should use any others django packages for PDF générating such weasyprint ?

Thanks

Hamza Khchine

--
You received this message because you are subscribed to the Google Groups "OHC-OPAL" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohc-opal+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OHC-OPAL" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohc-opal+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--------------------

David Miller

Open Health Care

openhealthcare.org.uk

[Khchine Hamza]

Yes.

I think we could consider http://weasyprint.org as good option to make it the default report engine for Opal. It become more popular and used by many django-based project.

In the case to consider this library . What would you suggest to add it to the Opal framework itself or to create a new plugin as a report engine?

Thanks.

Hamza

[David Miller]

Hi Hamza, 

That sounds like a good plan - I'd certainly rather write reports as HTML/CSS and then let a rendering engine compile them to PDF than write PDF documents by hand!

What we've found is that it's often easier to work on significant new features (like a PDF report engine) in a plugin, where the API can evolve and stabilize, before then looking at moving functionality into Opal itself.

For instance, the Pathway forms library, the Lab plugin... I think we're planning to write a generic 'timeline' plugin that way - with a view to moving it into Opal once it's mature.

Particularly early in projects like this the public API often goes through fast evolution - and the overhead of how we manage changes to Opal itself can slow this process down. 

For instance - doing that at the same time as maintaining full test coverage and documentation makes it more work, and as more people use Opal we try to avoid any backwards incompatible changes until a "major" release, and instead make sure the code issues warnings about pending removals. We also code-review every change to Opal quite closely - nobody merges their own work into the release branch. I'm confident that increases the quality of the code, but it also takes time!

Although that's the responsible thing to do with re-usable framework libraries that are used by many projects, when you're writing the first couple of versions it's more work than is really required :)

Of course if there are general purpose changes that make more sense to implement in Opal itself then individual PRs can make it easier. For instance, the Patient.bulk_update method is in Opal itself, but is there to enable features in the Pathway library and in Gloss (our integration engine for pulling / pushing data to other e.g. hospital systems)

Hope that helps and do get in touch if you have any other questions / etc :)

Best

David

[Hans MediPrepare]

Dear OPAL members,

I make use of https://wkhtmltopdf.org/ with good results. We can easily translate them as well. If you click demo button you may view the result. The generation of the PDF is automated, the design can be created by non-programmers (doctors f.e.) with a little bit of teaching.

Kind regards, Hans

https://mediprepare.com 

Op maandag 13 maart 2017 17:06:33 UTC+1 schreef Khchine Hamza: