[jifty-devel] Custom input processing on custom subclassed form
jesse at bestpractical.com
Wed Sep 27 20:49:09 EDT 2006
I've been meaning to reply to this for um. a couple weeks now, but I
keep not getting to it. I do think you're 100% right that a
Jifty::Web::Form::Field should have some sort of post-handler. I guess
the problem comes in that there isn't a way to know what form field
class rendered a given argument.
On Sun, Sep 10, 2006 at 02:07:18PM -0400, Sean E. Millichamp wrote:
> I decided to look at creating a custom form field after seeing the Wifty
> commit where the custom 'WikiPage' field was implemented.
> I succeeded in creating it for the display-side, but I feel that there
> should also be a hook for the post-side where the custom field can
> influence the argument_value that the Action sees.
> I looked at trying to implement this by trying to add a
> 'field_argument_processing' function in Jifty::Web::Form::Field that, by
> default, did nothing, and that was hooked in either when the incoming
> form values were processed or when fetching the value with
> argument_value in J::Action. However, as both places were for incoming
> data there were no existing references to the J:W:F:F objects and to
> create an action to get the render_as, just to then create a J:W:F:F
> object for the sole purpose of calling the function did not seem like
> the right way of doing it.
> I would like to solicit advice on if this is a bad idea (and why) and if
> it is a good idea (or, at least, not a bad one :), what the best
> place/way to do this in Jifty cleanly would be. If someone can point me
> in the right spots I will try to add it as a real feature.
> Why would this be useful?
> Take, for example, an application that has to deal with USD currency
> values throughout. Due to floating point issues, the safest way to
> store and manipulate USD currency seems to be to store and manipulate it
> as cents (an integer). However, people are used to relating to it in
> terms of dollars and fractions of dollars.
> Right now, this seems problematic with Jifty. To make sure amounts are
> always stored in the DB tables as integers you can do before_set_*
> functions to multiply the values by 100 and after_ to divide by 100.
> However, that means that if you want to do integer math between two
> different fields you must manually multiple each value by 100 and then
> divide the result before storing it. Okay, so then you say "I will just
> treat it as an integer/cents throughout". For display you can create a
> Mason filter method for normal display and create a custom form field
> for field_value displays.
> This seems ideal until you get to data entry. For data entry from forms
> you still need to be sure to multiply by 100 at every form entry point
> in every action (thus violating the tenant of DRY). If you have a lot
> of actions/fields throughout the app that are currency fields that
> leaves a lot of duplication and a lot of opportunity for forgetting to
> perform the conversion. There is no way that I can see where you can
> globally associate any incoming processing with a field type like you
> can on the outgoing side.
> I'm looking forward to feedback, thanks!
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
More information about the jifty-devel