Almost sounds like we end up with 3 operating modes:

1. production (strict validation, early halt)
2. production-relaxed (relaxed validation, no halt but with error
3. development (strict validation, exception/halt at the end after the
output is generated)

(following Glen, 1 would be the default)

Just as an idea: this could also be set through a custom attribute in
the FO file instead of (or in addition to) setting a parameter from the
command-line or through the API.

Anyway, I think Glen and Chris both raise valid points. Now we need to
decide what we really want to do. Personally, I was always happy with
the mode 2 above, so I don't have a strong opinion towards any solution,
as long as mode 2 is available. Doing it like described above is ok with

On 18.04.2005 10:24:30 Chris Bowditch wrote:
> 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

Jeremias Maerki

Reply via email to