[reportlab-users] Re: Philosophy on validation

[Benn Bollay]

Hey Andy,

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 :)
-B

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,


> Andy