[reportlab-users] Using report lab for generating database reports.

[Henning von Bargen]

I consider using reportlab as a reporting toolkit 
in conjunction with an Oracle database application.
Oracle provides a feature-rich reporting solution
called "Oracle Reports", but it is expensive
and the problem we have with it is that the end-user
can not modify the output.
Examples:

1. In order to change a text constant on the report,
the user has to edit the report definition file
(a binary format), so he has to open it
with the quite complex Oracle Reports Builder tool.

2. The same is true if the change should be done only
for one particular document and not for the report definition in general.
(this could be achieved with Adobe Acrobat)

3. Deleting, inserting or modifiying the length of layout elements
is much harder and can never be achieved in the resulting PDF file,
because page-breaks can change.
(usually, the position of all flowables following a flowable X in a story
depend on the position and size of A.

4. There are always some cases in which the layout algorithm
produces "ugly" page-breaks, even if 98% of the produces documents
look fine.
It would be fine if would could "manually override" the page-breaks.

My idea of an ideal reporting solution is that the resulting documents
is generated in two steps:
(i) The "story" file is created from the database data.
    This story could be RML markup 
    (sorry, but I think that RML is still too expensive)
    or just a python script that uses an application-specific class-library 
    based on the platypus package, but provides a simpler interface.
    Note that the story does not contain any code to fetch the data,
    it is just an ASCII representation of what will be printed.

    A simple story file could look like this:
    story.add (Header1 ("Hello World!"),
               Paragraph ("This is a simple example."),
               Table (rows=3,
                      cols=2,
                      content=[HeaderRow ("Column A", "Column B"),
                               DataRow ("A1", "B1"),
                               DataRow ("A2", "B2")
                              ]
                     )
              )

(ii) The resulting PDF file is generated and rendered, together with 3
buttons
    "Accept", "Modify", "Cancel".

(iiia) In most of the cases, the user will "Accept" the generated file
    and submit it (print it or send it via e-mail or just save it).
    The application could now save the story file together with the PDF file
    in an archive or in a document management system.

(iiib) In rare cases the end-user decides that he wants to
    make some slight changes to the document. So he clicks on "Modify".
    Now he can directly edit the story file - somehow.
    Then continue with (ii) again.
    When finally saving the files in (iiia), save both 
    the original story file as well as the modified version.

The easiest way to implement "somehow" would be to modify the file 
in an ASCII editor.
This would enable a not too dumb user to modify text.
A halfway clever user could also delete or insert paragraphs
and table rows into the story.
An expert user could even change the page-breaks by
- adding spacer objects or page-break objects into the story at the places
he likes
- adding space-before or space-after attributes of some elements.

A much more complex approach
(but I think _possible_ with ReportLab, compare the platypus debug mode)
would be to allow the user to change the story file by 
clicking with the mouse in the generated PDF file.
Then the cursor would be positioned at the corresponding position in the 
story file.

Even more complex approach: Complete GUI for editing the story file.

Is anyone already using reportlab this way at least thinking about it?
I'd also like to know if someone is using ReportLab for printing multi-page
nested tables.

Henning