Partial converstion of Group form to be an EntityForm
authoreileen <emcnaughton@wikimedia.org>
Mon, 25 Mar 2019 09:21:39 +0000 (22:21 +1300)
committereileen <emcnaughton@wikimedia.org>
Thu, 25 Apr 2019 05:01:33 +0000 (17:01 +1200)
commit7da21f11e4d5601341a5804baba370ee1bb432fb
tree33cc3748f128bd92bc392d7f76c186f931c120b5
parent824a466ba09638b44a337006a4e71e4fdb6764ae
Partial converstion of Group form to be an EntityForm

This is mostly for demo purposes and it should be noted that these changes are generally done in a
'step in the right direction' kinda way, and in accordance with this I have made a very minimal change.

 In this case the change gets the form to be using the entity form
and converts two field. The change didn't initially work for the title field because the schema didn't define the
html type for the field - fixing these things is a feature not a bug of switching to an entity form

We can remove the apply filter line  & the addButtons fn as the parent does these (actually it adds the custom
data too but I've left that out of scope).

If we converted a few more fields we would see that
1) the saved_search_id doesn't have a pseudoconstant defined in the schema, as it should
2) the various field description & help info is not in the schema
3) when we convert the tpl file we add custom data support in, although this form already has it

When we finally switch to a non-quickform layer the new forms will be built of the schema so by
transferring information into the schema and out of thousands of differently coded forms
we take steps in the direction of facilitating that.

That perhaps seems a little unachievable but the api was originally as incoherent as the form
layer and it was only by incremental cleanup it became more consisten
CRM/Contact/DAO/Group.php
CRM/Group/Form/Edit.php
xml/schema/Contact/Group.xml