On Dec 24, 2010, at 9:19 AM, DenesL wrote:
>
> On Dec 24, 2:21 am, Johann Spies <johann.sp...@gmail.com> wrote:
>>
>> I have it working now and it seems that the main thing I have changed to
>> make it work was to change the name of the field (from 'id' to something
>> else). I did not check afterwards in the documentation but I suspect that
>> SQLFORM.factory uses an 'id' field (hidden).
>>
> Makes sense since the handling of 'id' is special but only a trace
> will tell us why.
> There is no hidden 'id' field in SQLFORM.factory
I've been thinking about this one (generally, not the id issue specifically).
The semantics of accepts() is designed to catch form validation errors and
provide feedback to the client. It's not designed to diagnose form programming
errors, and many (most?) of those errors come back looking as though the form
had not been submitted (return False, nothing in form.errors).
That reinforces my notion that there ought to be another form variable to
provide feedback to the designer about why a form was not accepted, say
form.status. I realize that this might not always be clear-cut, in that in the
event of some form errors it's not 100% obvious whether there's an error or
there was no submission. But at least it'd be possible to describe what
accepts() thinks it saw.
The intent would be to help with development diagnostics, not so much for
deployment.
>>
>> What I could not understand was that when I the normal crud form in the html
>> there were two identical fields('id') although I had only one in my
>> definition. Changing the name of the field corrected that and the
>> redirection took place as expected.
>>
> What crud?.
>
