The way they work at the moment, they´re intended to be run on values
you set yourself: $field->default($obj)
such as when you recieve a DateTime object from DBIx::Class.
When you redisplay a form, the original submitted value is used.
Filtered / inflated values aren´t used, so it shouldn´t prove a
problem that the deflators are only used when it´s not been submitted.
Of course, this is only how I think it should work - the code might
differ from my memory! I´m also open to suggestions on how it might
work better, as well.
Thanks, I think I get the current status now.
my perception was that
$form->process()
runs Filters, Constraints, Inflators, and Validators and
$form->render()
runs Deflators before outputting xhtml to produce values to be used for
rendering.
Basically what I wanted to do was
1. Receive an form
2. Inflate an element to an Object
3. Refer to, and change some values of the object
4. Deflate the object back to a string and see its
results in the form.
For example, if I inflated a column to a DateTime object and then I
changed the value to be a year ago the specified date (and perhaps
explicitly set it as the value of that param), I was expecting the
change to be visible when render() was called.
I guess it's really the naming of the modules: there's an inflator, and
a deflator, I expected one to compliment the other. So if inflators
always run, then deflators always do too, or something like that.
I don't have too strong of an opinion as to whether this should be
changed to not -- I just thought that was a natural sequence of events.
--d
_______________________________________________
Html-widget mailing list
Html-widget@lists.rawmode.org
http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget
