[reportlab-users] Re: Philosophy on validation
rl at magitech.org
Fri May 5 13:34:20 EDT 2006
The more I think about this, the more I come around to this perspective: the
issue isn't one of data integrity at all, it's purely a question of data
representation. Is the data going to be represented as left-justified
normalized data? Right justified? Unidirectionally (is that a word?)
expanded, like an image?
RL doesn't care. Programmatically, it needs it to be in a normalized format
once it goes past a certain level, but how it's normalized is, in short, none
of RL's business.
So, back-peddling from my previous position, perhaps all that's really needed
are a couple utility methods (and associated documentation) to perform some of
those scalar operations we normally see for images to these text arrays. If
the user wants a particular formatting, then they can apply it prior to
passing it to the RL methods.
So, in short, I take it all back, out, and put it somewhere else :)
On Friday, May 5, 2006, 8:14:31 PM, you wrote:
>>>At the moment, we determine table width by looking at the longest row in
>>>the input data. I'll also add an OPTION to accept 'ragged edge' data,
>>>so you can set your tables to work that way if you wish.
> This might be worth a thread.
> Our position generally is to be as strict as we can about input.
> Usually we're building apps which slurp in data from all over the place,
> and it's better to flag up content problems early to the developers or
> calling systems. In the corporate world the data is ALWAYS a problem;
> the best we can do is tell the calling system that it's their problem,
> not ours!
> If we were 'relaxed' about input, we'd end up with more situations where
> it all runs, but the wrong output ends up on somebody's bank statement
> one day, or a chart is missing a series - unnoticed!
> The clearest expression of this philosophy is the graphics classes,
> which will complain immediately "on setting" if you set an inappropriate
> colour value, rather than silently failing to display your colour later
> on. But "ReportLab 3000" (don't ask for a date) will hopefully take
> this further and have very clear specification of what all the published
> objects are, their allowed values and constructors.
> The open source "API" is not a simple one where we can examine all
> input, and there are always back doors around it. In RML, we can be
> much more anal about rejecting bad input because it all arrives in a file.
> So, our defaults will generally be strict, but I am always happy to have
> options to relax things.
> Have a good weekend everyone,
More information about the reportlab-users