3

I've been working on an extension for civicrm and am using the API to retrieve fields to be used in forms presented to the end user.

I am using the 'html.type' returned to determine which type of html form input to display (text, textarea, select, etc.).

The first issue is that the returned values don't match up with html input types, for example:

CRM.api3('Contact', 'getfield', {
  "sequential": 1,
  "name": "birth_date",
  "action": "get"
})

returns

"values": {
    "name": "birth_date",
    ...
    "html": {
        "type": "Select Date"
    }
}

but Select Date is not an html input type. This isn't too much of a problem as long as Civi is consistent with what it calls a date field. But in the above example, the field birth_date expects a date without a time.

But calling

CRM.api3('Event', 'getfield', {
  "sequential": 1,
  "name": "event_start_date",
  "action": "get"
}

returns the same 'html.type' value:

"values": {
    "name": "start_date",
    ...
    "html": {
        "type": "Select Date"
    },
    ...
}

and yet this field expects a datetime, not just a date.

So if you're trying (as I am) to have an extension operate on a list of fields which can be selected by the user and so aren't known in advance, I can't see any way to differentiate between the two cases.

I may be missing something obvious, but I can't work out what.

1 Answer 1

1

We've worked this out to handle form creation for civicrm fields in the CiviCRM entity project. https://drupal.org/project/civicrm_entity

We use the 'type' property returned from a getfields api call like so: This code here we determine what widget to use: checkout civicrm_entity.module civicrm_entity_get_field_widget() the section pertaining to dates:

 if (isset($field_spec['type'])) {

        switch($field_spec['type']) {
          case 4:
            $widget = array('widget' => 'date_select','format' => 'Y:m:d');
            break;
          case 8:
            $widget = array('widget' => 'date_select','format' => 'H:i:s');
            break;
          case 12:
            $widget = array('widget' => 'date_select','format' => 'Y:m:d H:i:s');
            break;
        }
      }

so the '#type' of the form element is set to 'date_select' and the format is used to set the '#format' property this does require the date_api module from the Date project

1
  • Thank you, this looks like a good workaround, but I still think this shouldn't be necessary. Oct 31, 2016 at 20:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.