Also, looking at that link I just read: "In order to set a flash on the next page instead of the current page you must use session.flash instead of response.flash. web2py moves the former into the latter after redirection. Note that using session.flash requires that you do not session.forget()"
Which for the most part answers my question about the what session.flash does. It's automatically moved into response.flash after a redirect, which is exactly what I want. Funny how well thought out web2py can be sometimes. With out even reading the manual I ended up with the proper code (Setting session.flash on redirect) instinctively and it just worked. I would like to play with the keepvalues variable though, I don't really have a need to redraw the page just want the form to stay in sync. Now that I think about it I'm not clear why my form when I don't specify keepvalues changes on submission. I guess that's in the nuances of 'clearing' a form of check boxes which were pre-populated. On Jul 18, 2:09 pm, Chris S <[email protected]> wrote: > You know what I didn't even know about the optional keepvalues > argument. However reading on it here's how I see that working out > (I'll test to verify when I get a chance to code some more). > > Form loads, pre-populating check boxes based on current data in > database. > Submission is made > Form is reset to the original values (not including the changes that > were just made) > > I think that's going to produce the same problem I currently have of > the data being out of date. Since I'm trying to make a form which > always shows the same as the data currently in the database, I think I > have to do a redirect and force it to redraw the form. Though I would > love to hear if there's a good way to do this with out doing that. > > On Jul 17, 2:17 am, Rob <[email protected]> wrote: > > > > > I'd like to know the answer to this as well - what is the preferred > > way. > > > In the meantime, can you pass 'keepvalues=True' to your > > form.accepts() ?http://web2py.com/book/default/section/7/1 > > > The nice thing about doing the redirect is that you're not constantly > > bothered with the resubmit form data prompt if you go forward then > > back. > > > On Jul 16, 11:18 pm, Chris S <[email protected]> wrote: > > > > I've used response.flash before but I'm just not following the work > > > flow here. I'm sure I'm missing something easy so maybe someone can > > > point out what I'm missing. > > > > I'm using a SQLFORM.facotry to generate a form which consist of > > > several Boolean fields. It's built as a list of fields looking like: > > > fields.append(Field(name, 'boolean', label=name, \ > > > default=find_default(name))) > > > > In the view I display the various check boxes with the custom form > > > widgets. > > > > Everything works as expected when I check form.accepts I can set a > > > response.flash and it shows up. However, the check box does not show > > > the proper value until the page is reloaded. To account for this I > > > added a redirect at the end of the form.accepts to force a page > > > refresh. This worked but now response.flash doesn't show up. > > > > I actually accidentally fixed this when I made a typo and set > > > session.flash instead of response.flash as I normally did. So now I'm > > > left puzzled as it seems to work with the session.flash and a > > > redirect. > > > > Can someone briefly explain when response.flash vs session.flash > > > should be used? Additionally, does session.flash get cleared after > > > display or could it show back up somewhere else? > > > > Finally, is setting session.flash and redirecting the proper way to > > > use the 'flash' div and update a form for the current submission or is > > > there a better suggestion? > > > > None of this is crucial, just thought I understood this and stumble > > > across something I didn't even knew existed.
