----- Original Message ----- From: "Martin Aliger" <[EMAIL PROTECTED]> To: "'Gary Feldman'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, October 29, 2004 11:54 AM Subject: RE: [nant-dev] xmlpeek verbosity
> Exactly as Gary wrote! :-) > > > > But the <xmlpeek> task is definitely something different as a user > > > expects > > a > > > given property to be set to a value. If we don't output > > anything at a > > all, > > > when no matching node is found then that property will not > > be set and > > users > > > will have a hard time troubleshooting. By outputting a warning or > > > error message, users are at least notified that something did yield > > > the expected result. > > > > This is true, but what can they do about it? There will > > surely be cases where the user doesn't know in advance > > whether or not the node exists, and the .xml file is valid > > either way. NAnt treats this as a non-fatal error when > > failonerror is false, but this still seems wrong - it's not > > an error as far as the user is concerned, it's just different > > data. While the user could initialize the property to some > > value that isn't expected to occur in the file, and then > > interrogate the property to decide what to do, that's not an > > obvious tactic and it is a bit of hack. > > > > If you don't like the idea of failonerror="false" suppressing > > the message, then how about adding an attribute > > notfound="differentPropName"? If provided, and the result > > isn't found, then this property is set to true and no message > > is issued, otherwise it's set to false. The user who expects > > that the peek may feel can then just interrogate this > > property to decide what to do. > > Hmm - propably more consistent solution and also suppress that "hack". > There could be foundproperty (and we set it to true/false) and notfounddata > (which we would set into property if no matching node is found). > Message should be suppressed if either if those two is specified. > > +1 for this solution and I'm volunteer to code and contribute patch for > this. Wouldn't it just be better (and more powerful) to have separate tasks, or functions for this ? Gert ------------------------------------------------------- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/ _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
