On Oct 30, 2007, at 12:39 PM, mario ruggier wrote: > On Oct 30, 2007, at 5:31 PM, David K. Hess wrote: >> I'm not sure how I would apply that outside of an AJAX setting? >> I'm trying to reset the values of the form after it has been >> submitted but before it has been rendered for return to the client. > > I had a similar problem (I think, if i understand you correctly) > and that was to be able to apply field values (arbitrarily, > depending on some dynamic condition) onto a form (that is submitted > or not). > > I had opted for doing it as I describe below, but always had it in > the back of my mind that a rethink of how Form works for this is > probably needed -- I feel that there should be better support for a > real widget.set_value(), that is independent (a) of the widget's > default (init) value (b) of the incoming value in the > request.fields dict (c) of whether the widget is "parsed" or not. > > The logic for setting widget values seems (to me) too tangled up > with the logic for parsing incoming values on the request -- and > instead of trying to "untangle" that logic I just opted to "adjust" > the incoming values on the request... > > If you wish to look at the code in its real context, to maybe > understand the idea more clearly and whether it is applicable to > your problem or not, you may look at the gz.gizmo.gform module. In > that, the base GWidget has this method: > > def unparse(self, value, request): > # Does opposite of parse -- pushes a stored value onto > request field. > # Useful to "prefill" incoming form field widget from a > stored value. > self._parsed = False > request.fields[self.name] = value > > The "unparse" for some actual widgets assumed a variation of this, > e.g. the one for SingleSelect and Date. > > In your case I think you may want to reset values to some default > set of values (i.e always the same), but maybe the same technique > may apply. That approach looks like it would address what I'm trying to solve, and I think it touches on the crux of the difficulty. Form changes it's behavior implicitly by pulling values from the request based on whether is_submitted or has_errors ever gets called. Your unparse method completes the loop back the other direction. >> I suppose one way to use that would be to have some javascript >> that does a form reset on the client after it loads the form...? > > Submitting via AJAX changes the game significantly...but iiuc you > are submitting normally (form.action), i.e. reloading the entire > page? If so, having to return the rendered form with previously > submitted values that you want to clean up, and then sending js to > the client to do the cleaning up (I think client-side form.reset() > resets the form to the initial values that it was loaded with) > seems probably too error-prone (and maybe too much work!). I agree, it would be nice to avoid a client based solution. Besides, it will leak form values which might represent a security issue (e.g. a password). Dave