Author Topic: return. vs return (Read 675 times)

Eileen · October 11, 2010, 03:37:45 pm

So,

A very minor tidy up is that contact_get accepts return_ or return. (or return%) whereas some others only accept return.

Code: [Select]

    foreach ( $params as $n => $v ) {
        if ( substr( $n, 0, 6 ) == 'return' ) {
            $returnProperties[ substr( $n, 7 ) ] = $v;
        } elseif ( in_array( $n, $otherVars ) ) {

vs

Quote

foreach ( $params as $n => $v ) {
if ( substr( $n, 0, 7 ) == 'return.' ) {
$returnProperties[] = substr( $n, 7 );

I think they should all be the same & I propose they all be made like the contact (this means changing Contribution, Event, Group & Participant). Does anyone see a reason why the contact version should not be the standard?

xavier · October 12, 2010, 02:52:18 am

What's the benefit of accepting returntoto on the top of return_toto ?

On the returns, something that might be interesting to generalise is using return = ['fieldA','fieldB'] instead of return_fieldA => 1, return_fieldB => 1) ?

and so the rest/ajax interface would instead of
civicrm/contribution/search&return[participant_id]=1&return[contribution_id]=1&contribution_id=28

be
civicrm/contribution/search&return=participant_id,contribution_id&contribution_id=28

More compact and readable, isn't it?

X+

Erik Hommel · October 12, 2010, 05:51:41 am

Yep, I second that!

Eileen · October 12, 2010, 10:48:20 am

So,

You're saying this syntax return_fieldA=1 is a bit laborious & it would be better to pass in a comma separated list or array? Makes sense... we could add it to the list.

On the minor tidy up... does that standardisation make sense?

CiviCRM Community Forums (archive)

News:

Author Topic: return. vs return (Read 675 times)

Eileen

return. vs return

xavier

Re: return. vs return

Erik Hommel

Re: return. vs return

Eileen

Re: return. vs return