CRM-16130 Create CRM_Core_Form::addField method

The addField function sort of already exists in CRM_Core_BAO_CustomFiled::addQuickFormElement.
Most work shall be refactoring that function, i'll create a PR in the coming days / week.

I think starting over with a new function in CRM_Core_Form and borrowing bits from the custom field function might be a good approach.
Currently api.getfields represents core and custom fields slightly differently, one prerequisite to this might be to sort out some of those differences. I recently pushed up a change to give custom fields a pseudoconstant attribute. Another good tweak would be to make the html widget attribute match the way it is in core fields (keeping backward compatibility by not removing anything from the current array structure).

That's indeed what i concluded also, starting with the new function first, refactoring the other one out, and use the new function for custom fields also, indeed caused some extra troubles, those are better for a followup, where we could refactor the customfields also to use that function, but i'll start here with the core fields first.

I added a PR in https://github.com/civicrm/civicrm-core/pull/5456

Tim - In latest master checkout, saving the Organization Address and Contact Info form throws a fatal error (civicrm/admin/domain?action=update&reset=1) because the master_id element in $params['address'] is being populated by a string which is that elements 'title' (Master Address Belongs To). I'm wondering if this related to the changes your working on - possibly due to the fact that this field/element is not defined by this particular form ???

[address] => Array
(
[1] => Array
(
[master_id] => Master Address Belongs To
[street_address] => 330 Upper Terrace
[supplemental_address_1] =>
[supplemental_address_2] =>
[city] => San Francisco
[postal_code] => 94117
[postal_code_suffix] =>
[country_id] => 1228
[state_province_id] => 1004
[geo_code_1] =>
[geo_code_2] =>
[location_type_id] => 1
)

)

i'll check the address save error first thing tomorrow, don't think it's related however at first sight

This does indeed was related.
The problem was that the title value of a hidden element is used as the value for the element.
I filed a fix in https://github.com/civicrm/civicrm-core/pull/5881
Sorry!

No worries - glad my 'intuition' was on track so we caught it easily / early.

Tim - I'm running latest 4.7 checkout and ran setup.sh and rebuild/menu etc. but I'm not able to use the inline forms from Contact Summary (e.g. add/edit email; add/edit phone etc.). I'm setting "Network error ..." warning popup. In Firebug I see:

Exception: "Cannot determine api action for CRM_Core_Form"</b></p><pre>#0 /Users/dgg/git/crm_v4
.7/CRM/Core/Form.php(1189): CRM_Core_Form->getApiAction()

David, I can indeed confirm this bug. But i'm not really sure how it happened / how to fix it. I'll hope Coleman can help us out here.
The error throwen comes from
{{
/**

• Based on form action, return a string representing the api action.
• Used by addField method.
  *
• Return string
  */
  private function getApiAction()
  Unknown macro: { $action = $this->getAction(); dsm($action); if ($action & (CRM_Core_Action}

  }}
  And the address and website form return '0' as action for their form, this is CRM_Core_Action::NONE.
  This meens we indeed need to add more cases here, but i'm not sure how Coleman saw this? (and i'm not familiar with the if and single & syntax). I'll try to catch him on irc to help out here.

I think this is the right fix: https://github.com/civicrm/civicrm-core/pull/5963

One other problem I'm noticing: it looks like something changed wrt field lengths - they seem to be getting set to the same as the db length instead of the previous user-friendly adaptation:

@colemanw i created a followup at https://issues.civicrm.org/jira/browse/CRM-16629
This is only recently fixable.
Thanks for reporting.

Noticed that the label for 'Current Employer' changed to 'Current Employer ID' - related to using the <title> property from Contact.xml. Pushing a fix for that one, but we should keep an eye out for other cases where the <title> is not (quite) appropriate for user field label display.

https://github.com/civicrm/civicrm-core/pull/6318