[jifty-devel] Jifty::Action argument_values

[Jesse Vincent]

On Thu, Aug 31, 2006 at 05:45:59PM -0400, Nelson Elhage wrote:
> 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.

Your message makes lots of sense to me, but I worry about what 
default_argument_values implies and how it's distinct from the "default"
attribute of an argument. (There's also the matter of the gradual
transition of "Argument" to "Parameter" in this context. )

I also wonder if this would help with the current "constructor" mess.
We want to automatically and magically serialize certain argument values
in webfoms, without necessarily requiring every rendering of those forms
to display a widget.  Hm. Or maybe what we want to do is, when rendering
a webform, if an argument/parameter has a value other than the _internal_
default but we're not rendering a widget to edit it.

Does that make any sense?

> 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
> _______________________________________________
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
> http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
> 

--