On Sep 16, 2010, at 10:08 AM, Michael Ellis wrote: > Thanks, Jonathan. That's approximately what I had reasoned it must be doing, > but couldn't state as clearly as you have. > > So, if I'm now understanding it correctly, form.accepts() is roughly > equivalent to the following conditions: > > (request contains submitted form elements) and > (form key matches) and > (all elements pass validation)
That's pretty much it. And if it's false, you need to check form.errors for the case in which the submission has errors. > > The 'magic' is simply that clicking the submit button sends a second request > to the controller that created it. So the form object only seems to persist; > in actuality, it's recreated from scratch when the second request comes in. Right. And the form submits to the same controller because you tell it to (or let it do so by default). It's always *possible* to submit it elsewhere, but setting the forms action. But that can get very confusing. > > All of which explains why I was unable to store extra info in the form object > at view time and have it available after form.accepts() came back True. Yeah. Depending on what you're after, you can create a hidden form element and get it back in vars, or maybe put it in session. > > Is that a fair summary of how it works? I think so, yes. Now if only DAL objects were as easy to understand.... > > > On Thu, Sep 16, 2010 at 11:04 AM, Jonathan Lundell <jlund...@pobox.com> wrote: > On Sep 16, 2010, at 7:26 AM, Michael Ellis wrote: > > > > I was never much bothered by either of those issues, but there is one > > bit of 'magic' that did (and to some extent still does) confuse me. > > I'm wondering if it might be worthwhile to give an detailed > > explanation what goes on in form.accepts(). > > > > When I first saw the idiom > > > > if form.accepts(): > > ... > > return dict(form=form) > > > > my assumption was that the call to form.accepts() was somehow > > rendering and transmitting the page and waiting for a user response. > > But then, I wondered how that could be since the form isn't passed to > > the view until the return() is executed. Then I tried tracing a > > controller and saw that it was being called multiple times. I got > > lost down in the gluon code and more or less gave up trying to find > > out exactly how the rabbit gets into the hat. Now I just use it and > > trust that it works, but it still bothers me not to know what's going > > on under the hood. > > I've had the same reaction. The key to my understanding form.accepts, fwiw, > was reading accepts itself. Keep in mind that web2py encourages form > self-submission. That implies that the same code (controller/function) > typically needs to run twice: once to create the page+form for display, and > again to handle the form's submission. > > So form.accepts() is telling you whether it's the first time through, form > creation (False) or the second, form submission (True). It's a little more > complicated than that because of validation and error handling, but that's it > in a nutshell. > > >
