Glen Mazza wrote:
Team,

<snip/>


Take two scenarios here:

1.) 200-page report containing dozens of tables. If
the user messes up the template match for any of those
tables, that 200-page report just printed will need to
be redone. But if we validate (i.e. halt) by default
we may very well have saved someone 200 sheets of
paper.


Relying on the user to scan FOP's output log after a
document run to determine whether or not their
document had every table generated properly would be
IMO too irritating for the majority of users.  They
are more likely to print a document without noticing
that the table on page 157 is erroneously empty.  For
these users, I think they would have been happier had
FOP halted and informed them of their bug instead.

2.) Invoice statements going out to large numbers of
customers.  It can happen for SQL errors to occur that
erroneously result in no XML rows being available for
certain of the invoices.  Under these conditions,
wouldn't most people in charge of the invoices be
happier if FOP halted with the error message, rather
than send erroneous invoices to those customers?  (It
wouldn't matter if an error message was written to the
logfile--that invoice would still be going out.)  Not
validating can introduce some nasty risks with
invoices--it is usually safer not to print it at all
then to send a bad invoice.

Both of these points are valid concerns. What the software developed by my company does, is it gives the user a flag: Error on Warning, which places the choice firmly with the user. The software then scans the log and halts the job before it is sent to the printer if this flag is set. However, there are many sceanrios where it is not desirable to just halt, hence why this decision should be up to the user not the FOP development team. An example of a situation where just always halting would be bad:


Our software allows users to preview what their document looks like before it goes into production. I would imagine most stylesheet designers would preview their work before releasing it to a production environment. If the user is just presented with an error message, with no output then the user will have to trawl through various places to work out what theyve done wrong. If they have the output and an error, it is easier for the user to locate the problem.

<snip/>

Chris



Reply via email to