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 messages) 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 me. 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
