[jifty-devel] Custom input processing on custom subclassed form fields

[Jesse Vincent]

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. 

-jesse


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!
> 
> Sean
> 



> _______________________________________________
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
> http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel


--