@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
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 an
If I need to use a "workaround" to perform the most basic needs of a
system, then that system is flawed to begin with.
A form system, by its very nature of what it is, should require 100%
customization ability without ugly, undocumented hacks.
--
Thadeus
On Tue, Jul 27, 2010 at 9:53 PM, Iceb
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
perfect. Thanks Massimo! I owe you one.
--
Thadeus
On Tue, Jul 27, 2010 at 7:32 AM, mdipierro wrote:
> I looked into it. What you are trying to do was never supported.
> hideerror was a machanism for allowing certain custom widgets to
> explicitly hide error or decide where to display them.
I looked into it. What you are trying to do was never supported.
hideerror was a machanism for allowing certain custom widgets to
explicitly hide error or decide where to display them.
I say "was" because I just implemented it the way *I think* you expect
it to work. Works with custom forms as wel
Until this is resolved this is how I usually handle the situation.
form=SQLFORM()
if form.accepts()
errors,form.errors=form.errors,{}
return dict(form=form,errors=form)
Unless you do this the philosophy is that widgets handle their own
errors and they can be customized by overridi
Let me look into this. I am sure there is a way to do it. I just never
use custom forms myself.
Is the problem with your own widgets? Do you assign widgets
explicitely? Can you post an example?
Massimo
On Jul 27, 6:00 am, Thadeus Burgess wrote:
> This has been a problem for quite some time, I ju
This has been a problem for quite some time, I just did not get around
to complaining about it again until now =)
If I am to use a custom form (which I almost always do). Then I can't
have my form elements going off and rendering their own errors now can
I? Not very enterprisey of SQLFORM to just
It is the INPUT widget that upon serialization displays the errors. I
can see it may be a problem with custom widgets.
On Jul 27, 4:42 am, Thadeus Burgess wrote:
> There is no possible way it can. Looking through the source code, it
> never passes along the extra attributes to anything. The curre
There is no possible way it can. Looking through the source code, it
never passes along the extra attributes to anything. The current way
the widgets are implemented never use attributes passed to them.
--
Thadeus
On Tue, Jul 27, 2010 at 4:13 AM, mdipierro wrote:
> I am surprised it does not
I am surprised it does not. can you help debug.
Try form.errors.clear()
On Jul 27, 2:29 am, Thadeus Burgess wrote:
> I don't get it
>
> SQLFORM.factory(Field., hideerror=True).
>
> It doesn't do what its supposed to.
>
> How can I make sure that none of my widgets render errors alongside
12 matches
Mail list logo
