On Apr 6, 4:38 pm, Kevin Butler <[email protected]> wrote:
> 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.
Without getting into this, a class behavior (accepts) acting on the
class is fine; setting internal state (e.g. form.vars) is ok;
Never called twice.... is .... perhaps worthy of some higher level
discussion.
Suffice it to say, at the very least, calling form.accepts() twice
should not do anything harmful, and should behave in _some_ reasonable
way (minimally: throwing an exception, or return indicator).
>> 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 ):
Regardless - given the constraints Massimo laid out, this should work:
form_accepted = form.accepts( requests.vars, session)
if DEBUGGING: debug( "Form accept: %d..." % form_accepted)
if form_accepted:
....
- Yarko
> ...
>
> 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.
