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

[Sean E. Millichamp]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20060910/767d395b/attachment.pgp