[reportlab-users] RE: Visual editor: what are the objectives?

[Henning von Bargen]

Fernando Lujan wrote:

> 
> A nice tool indeed.
> So, Let's light the oven and starting baking...
> Who have time, will and knowledge to lead this project?
> And... will we use wxpython?
> Let's not let this idea die in vain...
> 
> Fernando Lujan

Excuse me, but I still do not know about the goals of
the visual editor. These should be defined first, IMHO.

Do you want a visual designer just for prototyping the layout?
Then perhaps the easiest solution is to use a converter from
an existing graphic designer output format, like EPS.

On the other hand, do you want a visual designer for developing
(or: aid in developing) dynamic reports, i.e. database-driven?
Then you have to decide if you want he designer just as a
prototyping tool (which makes no sense, since you could use a
static document as as prototype as well, and just use an EPS importer).

Or do you want the visual designer NOT just to be a prototyping tool.
Then there's another decision to make:

Which input (source) formats and output formats should be supported
by the designer?

There's quite a lot of choices here as well.
Just a few examples:

(A) Input: a self-designed XML-based or 'pythonic' format.
    This can be edited and saved by the visual designer.
    Output: A python program using RL platypus. 
            The resulting PDF is then generated by calling the
            generated python program.

(B) Input: A python program using RL platypus that is following
           some convention.
           This can be edited and save by the visual designer.
    Output: Same format as input.

(C) Input: ...
    Output: a PDF file.

(D) Input: ...
    Output: a RL python program using the low-level PDF drawing operations
           (not platypus).

Let's see what the pros and cons are:

(A)
++ This is probably the easiest to develop (compared to the others).
- Uses a proprietary file format.
+ If the file format is XML-based, it can at least be used by other
programs,
  i.e. to generate prototypes from SQL-Queries etc, or for searching and
  replacing text constants.
- Sooner or later, the developer will find something that he/she can not do
  with the visual editor, so there's a need to add some cutom code to the 
  output.
  On the other hand, it could be possible to define something like a
  special tag to the format, where the developer can add python code
  (something like the <% and <%= tags in JSP), so this is only a small "-".
  Though it is harder in python than in Java, since you have to be very
  careful about indentation!

(B)
++ This would be the most effective solution (i.e. a report could be
  developed in the shortest time using the Visual editor in this way.
-- This could be very hard to implement.
Note: This approach is used by most Java IDEs.
++ It would be possible with this kind of tool, to output a python
   program that reflects a STATIC SNAPSHOT of the dynamic data,
   and to VISUALLY hand-edit it in the tool, i.e. to fine-tune the
   page-breaks etc. - see the comment on (C) below.
   This would allow fine-tuning the output even for non-programmers.

(C)
-- I don't like it, because it is impossible then
   to edit the generated output later.
   For example, if you have an editable,
   human- (to be more precise: programmer)-readable intermediate 
   output format such as a python program as in (A) or (B),
   then it is possible to fine-tune the output later,
   for example you could correct typos or insert page-breaks where
   you like them.
   And you could generate other output formats than PDF from it.
   All this is not possible if the tool emits PDF directly - you
   have to accept it as it is, then. I know what I'm talking about;
   we have a long report-development tradition in our company,
   and it is practically IMPOSSIBLE to make the page-breaks look
   nice just by applying fixed rules to dynamic data.
   No, please don't tell me about LaTeX, it's got nothing to do 
   with it, and it is not well suited for generating long tables 
   from dynamic data.

(D)
-- for the same reasons as (C).

One final remark:
Instead of "python program using RL platypus", one could substitute 
"RML file". But then one would need to buy the RL commercial product
for using the tool, which is still quite expensive IMHO.
If the RL commercial team developed such a visual editor tool in a
quality comparable to Oracle Reports, for example, then I'm sure
many developers would buy it for a reasonable price.

Henning