CiviCRM Community Forums (archive)

I am not sure Xavier....would I not use it in the same way as I now look at the documentation? In other words, would not updating and extending the documentation achieve the same goal? Or am I overseeing something?
Erik

Sorry I'm assuming you meant the explain thing ?

Obviously, the main goal is to get rid of the boilerplate code in the api (and to do something nice in Briton)

X+

Hi Xavier,

I believe the code is more likely to be kept up-to-date than the documentation - especially if it affects functionality. What happens is that often we spend an afternoon trying to figure out why something doesn't work like it should, digging through the code. Then we finally get it, pass in the 'right' params & go home & maybe mention it on the forum. Whereas, if the code were 'in our way' we'd probably submit a patch.

However, there are 2 functions that can do some of our work for us:

$fields = CRM_Pledge_DAO_Pledge::fields( );
$customFields = CRM_Core_BAO_CustomField::getFields($customDataType);

Both of these will return details about the fields. The DAO function returns the unique name of the field not the table name & there is some question as to whether the unique name is acceptable

The fields function returns required fields too - although in the case of pledges I added a couple more to the list that I considered required:
 'start_date' because I needed at least one of start_date, create_date or scheduled_date for the others to default to - it would accept without but the entry created was unacceptable.
'installments' -not a db field at all but required for it to work. I  was too lazy to write the code that says 'installments, amount, installment_amount - 2 out of 3 ain't bad.

I'm seeing them interacting with your function idea to form part of this array:

$statusParam=_civicrm_validate_param ("{
mandatory: {'contact_id','secondparam'...}
integer: {'contact_id','rowCount'},
string: {'secondparam"},
default:{'rowcount': 25}
}");
if ( civicrm_error( $statusParam ) ) {
        return $statusParam;
    }


So that we don't hand maintain an array like that for each API - a function would generate an array like that from the custom_fields & dao fields + another function that is generic to all the apis (with rowcount etc). But we'd still have to hand-add a small number like 'soft_credit_to' for contributions I think

The function is civicrm_verify_mandatory, resides in api/v2/utils.php and it checks if the params is an array, and if the passed mandatory fields are in the params. A call is included in the Tag API:
function civicrm_tag_create( &$params )
{
  _civicrm_initialize( true );
  try {
   
    civicrm_verify_mandatory ($params,'tag',array ('name'));

    if ( !array_key_exists ('used_for', $params)) {
      $params ['used_for'] = "civicrm_contact";
    }
   
    require_once 'CRM/Core/BAO/Tag.php';
    $ids = array( 'tag' => CRM_Utils_Array::value( 'tag', $params ) );
    if ( CRM_Utils_Array::value( 'tag', $params ) ) {
        $ids['tag'] = $params['tag'];
    }

    $tagBAO = CRM_Core_BAO_Tag::add($params, $ids);

    if ( is_a( $tagBAO, 'CRM_Core_Error' ) ) {
        return civicrm_create_error( "Tag is not created" );
    } else {
        $values = array( );
        _civicrm_object_to_array($tagBAO, $values);
        $tag = array( );
        $tag['tag_id']   = $values['id'];
        $tag['is_error'] = 0;
    }
    return $tag;
  } catch (PEAR_Exception $e) {
    return civicrm_create_error( $e->getMessage() );
  } catch (Exception $e) {
    return civicrm_create_error( $e->getMessage() );
  }
}