On Apr 2, 6:28 pm, mdipierro <[email protected]> wrote: > #1 > > form.accepts is a filter that moves request.vars into form.vars after > parsing and also populates form.errors. accepts should never be called > twice. Why do you want to do it? I am sure there is a different way to > achieve what you need.
I ran into it when I added a debug logging statement. When I changed: ... if form.accepts( request.vars, session ): ... to: debug( "Form accept: %d..." % form.accepts( requests.vars, session )) if form.accepts( request.vars, session ): ... My log statement showed that the form was being accepted, but the accepted form would never process successfully. The workaround of course is to make it: ... accepted = form.accepts( requests.vars, session ) debug( "Form accept: %d..." % accepted ) if accepted: ... But the cause of the failure was not immediately obvious. The side- effect of the "accepts" call making a subsequent "accepts" call fail was very unintuitive to me. > #2 > > web2py retrieves sessions before your application code is executed, > i.e. before your class is defined. therefore if an instance of the > class was serialized in the session, it cannot be serialized. Bottom > line: you cannot store your own objects in a session unless you pickle > and unpickle them yourself. Yeah. I think that restriction is fine. I actually expected to see an error message when I added the custom class - but silently creating a new session threw me. Thanks kb > > On Apr 1, 6:09 pm, Kevin Butler <[email protected]> wrote: > > > > > I spent way too much time figuring out what was happening with these > > two issues, because their interaction sent me debugging various wrong > > paths. > > > But in essence, I found two behaviors that were unexpected and which > > not provide an easy way to identify the problem. > > > #1) If you call form.accepts a second time, it always returns false. > > > That is, in the following code, you can get a "You have to enter a > > value" or "True then false", but you can never get "You can't get > > here": > > > def index(): > > form = FORM( > > INPUT( _name="value", requires=IS_NOT_EMPTY()), > > INPUT( _type="submit" ) > > ) > > if form.accepts( request.vars, session ): > > if form.accepts( request.vars, session ): > > response.flash = "You can't get here" > > else: > > response.flash = "True then false" > > else: > > response.flash = "You have to enter a value" > > > return dict( form=form ) > > > Is this by design? Why? If it /is/ by design, can we please have the > > second "form.accepts" throw a nasty exception so we can avoid it? > > > #2) If you store an instance of a custom class variable in a session > > variable, you will invisibly get a new, clean session on the next > > request. That is, in the following code, you can get "We'll get it > > next time", but you just can't get "You can't get here" (unless you > > cheat) > > > class X: > > pass > > > def index(): > > if session.nextTime: > > response.flash = "You can't get here" > > > session.x = X() > > session.nextTime = 1 > > response.flash = "We'll get it next time" > > > return dict( session=session ) > > > I imagine this is happening because of something like unpickling in > > the framework (maybe?), but instead of silently getting a new session, > > I'd much again much rather have an exception thrown... > > > kb -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
