[jifty-devel] Jifty::Action argument_values

Nelson Elhage nelhage at bestpractical.com
Thu Aug 31 17:45:59 EDT 2006


While trying to fix a bug reported on #jifty, I've been looking
through our argument value handling code in Jifty::Action, and decided
that the way we handle argument values internally is kinda weird.

Specifically, we treat values passed in from the Request, and values
passed in to C<new> or by C<argument_value> by user code
identically. This results in us using C<sticky_on_failure> as the
mechanism whereby arguments specified at run-time make their way into
rendered fields as default values, which feels wrong and kludgey. It
also creates bugs, in that we were considering actions that have had
arguments passed in the request, but which were not run (typically
because of the presence of J:ACTIONS that didn't include them), to
have failed for the purposes of stickiness. Fixing this bug breaks the
propagation of arguments passed to C<new> to rendered form fields.

The solution seems to me that actions want to have both
C<argument_values> and C<default_argument_values> to distinguish
between values we were actually given (which should be handled via
stickiness when rendering form fields), and values which came from
user code, via, e.g. C<new>, which should be used as defaults no
matter what.

The API upshot is that in addition to C<argument_value>, we would have
a C<default_argument_value> accessor, and that C<new> would accept,
e.g. C<arguments> and C<default_arguments> parameters, the latter of
which would be advertised for use in user code, and the former of
which would be used in C<Jifty::Web::new_action_from_request>. I also
like this, since I feel like passing C<default_arguments> better
connotes that these arguments are used when rendering fields only, and
won't be automatically serialized or otherwise saved for you -- I
found this quite confusing for a while when I was first learning
Jifty.

This change makes sense to me, and I think it can probably be
implemented backward compatibly. But, since this is an area so central
to Jifty, I wanted to ask the list if people either think I'm looking
at this all wrong, and introducing needless complexity, or if anyone
sees architectural reasons this proposal would be a bad idea.

- Nelson


More information about the jifty-devel mailing list