bug in new code for custom functions

[sarangtc]

the 2019-01-10 update in code which "Changed syntax for input/output controls and validation, backward compatible."

has an error for user defined functions. the complete $command is no longer passed to the function, but the $type is passed instead of $command

Upon looking at the class the following changes need to be made:
in the get_input_control function
change:
elseif(is_callable($type))
return call_user_func($type, $column_name, $value, $type, $called_from, $validate_placeholder) . $validate_tip . $validate_error_msg;

to:
elseif(is_callable($type))
return call_user_func($type, $column_name, $value, $control, $called_from, $validate_placeholder) . $validate_tip . $validate_error_msg;

and similarly in the get_output_control function
change:
elseif(is_callable($type))
return call_user_func($type, $column_name, $value, $type, $called_from);

to:
elseif(is_callable($type))
return call_user_func($type, $column_name, $value, $control, $called_from);

without this fix, the user defined functions are not backward compatible either.

Thanks for a great class. I am coming up with lots of functions that may help others. don't know where to post them though. Or shall I email them?

[lazymofo]

Looks like this could have been done better. I'll see if there's a fix preserving proper backward compatibility. Thanks.

[lazymofo]

Just curious, did this update break your code?

I feel like any fix results in a worse outcome.

For a little background, this parameter is not used too often. It holds the control name, which used to look like this "--my_control". In the new version the string comes through as "my_control".

If I "fix" this depending on how the control is setup (old --prefixed, versus new array), then output will vary on setup, which I don't like.

I'd rather the output be consistent and possibly break a little backward compatibility in this case.

[sarangtc]

I had just written a custom function which I needed to pass parameters to
to make it dynamic and reusable without having to change the function.
(Mainly sql query, sometimes custom delimiter).
I was finding it not so ideal to parse the string into parts because it
would be impossible to predict the delimiter to split on as one of the
things I wanted to pass to the function was a user defined delimiter.
Then I remembered that you had changed the syntax which may allow me to
pass anything as a variable to the function.
On updating the class, yes my code broke, but primarily because only "type"
(without the preceding --) was being passed in the $command, so I fixed
that by changing the functions as described above (which is the urgent fix
that is needed), then realised that $command is not backward compatible.

As I was still in the process of writing my custom functions (which I will
hopefully share once you make a decision on updating the $command bug), it
was not an issue for me.
But I request that although it will not fix the "backward compatible"
promise, making the changes specified above will at least fix the bug.

basically in both the get_input_control and get_output_control
functions:
in the:
return call_user_func($type, $column_name, $value, $type,
$called_from.....
need to change the second $type to $control
to read:
return call_user_func($type, $column_name, $value, $control,
$called_from.....

this passes the complete array of parameters to the $command variable as promised

[lazymofo]

Sorry, I'm going to stick will will not fix. I can't just swap $type for $control. $control is now an array. The only "fix" I could apply would be prefixing the $type with "--" if a old style control was defined; but then behavior in custom controls would be affected by calling style. There's just no good fix in my opinion.

…

On Fri, Aug 23, 2019 at 10:05 PM sarangtc ***@***.***> wrote: I had just written a custom function which I needed to pass parameters to to make it dynamic and reusable without having to change the function. (Mainly sql query, sometimes custom delimiter). I was finding it not so ideal to parse the string into parts because it would be impossible to predict the delimiter to split on as one of the things I wanted to pass to the function was a user defined delimiter. Then I remembered that you had changed the syntax which may allow me to pass anything as a variable to the function. On updating the class, yes my code broke, but primarily because only "type" (without the preceding --) was being passed in the $command, so I fixed that by changing the functions as described above (which is the urgent fix that is needed), then realised that $command is not backward compatible. As I was still in the process of writing my custom functions (which I will hopefully share once you make a decision on updating the $command bug), it was not an issue for me. But I request that although it will not fix the "backward compatible" promise, making the changes specified above will at least fix the bug. basically in both the *get_input_control* and *get_output_control* functions: in the: return call_user_func($type, $column_name, $value, $*type*, $called_from..... need to change the *second* $type to $control to read: return call_user_func($type, $column_name, $value, $*control*, $called_from..... this passes the complete array of parameters to the $command variable as promised — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45?email_source=notifications&email_token=ABRM2WEOL6GW5WBA3A4U6QDQGC6P7A5CNFSM4IK3X2QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5BY2KA#issuecomment-524520744>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRM2WBRYGLLLT4RZJFGLQTQGC6P7ANCNFSM4IK3X2QA> .

[sarangtc]

Just curious, did this update break your code?

I feel like any fix results in a worse outcome.

For a little background, this parameter is not used too often. It holds the control name, which used to look like this "--my_control". In the new version the string comes through as "my_control".

If I "fix" this depending on how the control is setup (old --prefixed, versus new array), then output will vary on setup, which I don't like.

I'd rather the output be consistent and possibly break a little backward compatibility in this case.

I think there is a some sort of misunderstanding:
BEFORE the new format of form/grid input/output controls

the format was:
$lm->form_input_control['weird_data'] = '--my_user_function';

function my_user_function($column_name, $value, $command, $called_from){

// $column_name: field name
// $value: field value  
// **$command**: **full** command as defined in the arrays: form_input_control, grid_input_control, or grid_output_control
// $called_from: which function called this user function; form, or grid

global $lm;
$val = $lm->clean_out($value);
return "<input type='text' name='$column_name' value='$val' size='100'>";

}

so
if my user function was:
$lm->form_input_control['weird_data'] = 'select my customsql; mycustom string; --my_user_function';
when I called this $command variable in the custom function, I used to get
'select my customsql; mycustom string; --my_user_function'
returned to me (not just '--my_user_function')
which was a useful way of passing custom sql or parameters to the function, so one function fits all, like you do with select and selectmultiple

is this what you experienced too?