@Thadeus & Massimo, I used to think the form.errors is a part of formal return value of FORM.accepts(...), therefore it is not just a "trick" or "workaround", it IS considered as kind of an API, albeit not well documented perhaps, neither well known.
But since the accepts(..., hideerror=False) is implemented now, it is also good. Thanks for your input. Regards, Iceberg On Jul 28, 1:01pm, mdipierro <[email protected]> wrote: > Because the SQLFORM/FORM API did not provide a hideerror option (until > now) the solution was a trick: > 1) move the form.errors into a new local variable errors > 2) clear form.errors so that FORM/SQLFORM did not display any > > hideerror=True is cleaner because it do not require using a local > variable and because errors stay where they belong in form.errors and > when not displayed. > > Massimo > > On Jul 27, 9:53 pm, Iceberg <[email protected]> wrote: > > > > > Sorry, can someone clarify the difference between the "workaround": > > errors,form.errors=form.errors,{} > > and the new feature: > > if form.accepts(....,hideerror=True) > > ? > > > I think the former is straightforward. > > form=SQLFORM(....) > > if form.accepts(....): > > # all data are perfect > > do_something() > > # And I can still deal with the errors, if any > > errors,form.errors=form.errors,{} > > return dict(form=form,errors=errors) > > > Then when and how to use the "hideerror" feature? Is it? > > form=SQLFORM(....) > > if form.accepts(....,hideerror=True): > > do_something() > > # but wait, are all data ok, or just some error being hidden? > > return dict(form=form) # And where is my errors? > > > Regards, > > Iceberg
