Author Topic: API extra params, that's getting out of control soon (Read 1798 times)

xavier · April 13, 2011, 01:12:51 am

The params where supposed to be attributes of the entity, used either to create/modify or as filter.
We already added a few extra "filters" that didn't fit in
return, rowCount, sort
and some more for formatting
is_sequential and json

And probably quite a few here and there, eg create_new
http://forum.civicrm.org/index.php/topic,19408.msg80906.html#msg80906

Should we use a common prefix to identify the "behaviour" from the regular field names (and avoid potential conflicts of names).

eg. feature.create_new instead of create_new ?

Eileen · April 17, 2011, 03:19:27 pm

I vote that anything with a . in it is 'special' & we have

filter.is_current
filter.option_group_name

for anything where the param is not part of the DAO (that second one is in the context of optionValue & I included it in the e.g as it is a bit border list

api.action.entity
api.create.contribution
api.delete.participant

(for chained functions - we don't want to rely on the actions ALWAYS being crud so something extra like 'api' seems good & warm_beer was too long). We could reverse the action & entity as the assumption is that with no action it would be the same as the parent. Also, per prev discussion the api lot will (eventually) take a string or an array

option.sort_by
option.is_sequential
option.aggregate_by
option.row_count
option.create_new - defines a specific behaviour for the pledge api

or something similar

return.field_name

per now

EACH api would need a function like :

civicrm_apiv3_event_special_fields($action){

switch ($action){
case : "create"
break;
case "get" :
$features = array('filter.is_current');

}
return $features;

}

Erik Hommel · April 18, 2011, 12:11:30 am

Makes sense!

xavier · April 20, 2011, 03:55:25 am

Quote from: Eileen on April 17, 2011, 03:19:27 pm

filter.is_current
filter.option_group_name

IMO that is_current or that the group name are calculated are implementation details that shouldn't leak to the API.

As Eileen pointed out, they should be in the get fields (and that action is now a param on getfields)

i'd vote to keep it like that and improve the getfield.

Quote from: Eileen on April 17, 2011, 03:19:27 pm

api.action.entity
api.create.contribution
api.delete.participant

(for chained functions - we don't want to rely on the actions ALWAYS being crud so something extra like 'api' seems good & warm_beer was too long). We could reverse the action & entity as the assumption is that with no action it would be the same as the parent. Also, per prev discussion the api lot will (eventually) take a string or an array

api.entity.action seem to be a better order, eg api.contribution.create (like for civicrm_api)

Quote from: Eileen on April 17, 2011, 03:19:27 pm

option.sort_by
option.is_sequential
option.aggregate_by
option.row_count
option.create_new - defines a specific behaviour for the pledge api

like it.

Quote from: Eileen on April 17, 2011, 03:19:27 pm

or something similar

return.field_name

Eileen · May 22, 2011, 10:17:29 pm

I think this is becoming topical again so adding the contents of the latest email I have on what a nested api would look like. Hope this extract makes sense - it did once

civicrm_api('Contact','Create', array('version'=>3, 'id' =>3,
api.email.create => array('email' => mail@mail.com'),
);

ie. if api.entity exists then call that function using the result of contact_create as contact_id. If the .create is left off assume same as parent function. If an xx_id is passed into the function don't assume contact_create as contact_id.

can then be extended to

civicrm_api('Contact','Create'
,array('version'=>3, 'id' =>3,
email.create => array('email' => mail@mail.com')
tag.entity.create => array('tag' => 42, entity_id => '$contact.id')
);

or
civicrm_api('Contact','Create'
,array('version'=>3, 'id' =>3,
email.create => array (
array('email' => mail@mail.com') ,
array('email' => mail2@mail.com') ,
),
tag.entity.create => array('tag' => 42, entity_id => '$contact.id')
);

CiviCRM Community Forums (archive)

News:

Author Topic: API extra params, that's getting out of control soon (Read 1798 times)

xavier

API extra params, that's getting out of control soon

Eileen

Re: API extra params, that's getting out of control soon

Erik Hommel

Re: API extra params, that's getting out of control soon

xavier

Re: API extra params, that's getting out of control soon

Eileen

Re: API extra params, that's getting out of control soon