Author Topic: De-quickforming or Quick deforming QuickForm (Read 910 times)

Eileen · June 10, 2013, 01:54:27 am

As the sprint is about to start in France one thing other than fine wine the sprintees might like to think about is ... quickform. No you are right - it's the last thing they want to think about

However, it occurs to me that the perennial complaints about quick form are not really about quick form after all. The complaints are that the developers have to interact with Quickform. I don't really know what symphony will bring but my suspicion is that if it's the same hooks developers may not find it the panacea to quick forms ills.

It seems to me the real complaint about quickform is that the hook passes the developer a form object rather than a nice array to alter. So, looking at one of the most commonly-altered forms Contribution form. if the buildForm process built an array of all the things it is about to assign to the form and then called a function (reallyBuildForm) with a hook at the start of reallyBuildForm then developers could alter than array much more comfortably and then reallyBuildForm - inherited from CRM_Core_Form could do all the assigning at that point.

Likewise on the postProcess it seems there are 2 parts - extracting the data from the form & the processing function. Ideally if postProcess pulled the variables out of the form & then called a process (e.g. processFormValues(&$params)) which didn't rely on the form, but only on the params passed into it we would have a function that was

1) unit-testable
2) callable from a different place (e.g. a drupal built form)

Of course doing this all over the place would be a huge job. But it could be done on a few forms in the first instance, without causing many problems

xavier · June 10, 2013, 07:00:36 am

you don't think about fine wine, fine wine thinks about you.

About quick form, my pet issues (beside the weird impression of code that was written when the dinosaurs were still alive)

1) that I need to manually code the form/validation in the first place, once in php and the once again in the template and manually list all the fields, as most of the stuff should/could be found out directly from the schema (and most of the time we don't have an "exotic" layout for these forms).

2) the params to each field type is undocumented and a bit of trial and error

3) from the hook perspective, the how to find/alter/remove/make mandatory/set the default value for a given field is again not that "natural" and documented (especially if dealing with profiles if I recall)

4) The object per itself isn't the issue IMO, but it's undocumented and some attributes are protected, haven't found the logic of why (but given there is a generic getter and setter, has a limited utility/impact)

5) dealing with fieldsets/groups of fields. same weirdness than above, even less documented

On drupal8, the hooks seems to be replaced by dependencies injections and observers (as symfony it seems), that might be helpful we follow that pattern too?

X+

Eileen · June 10, 2013, 11:52:57 am

hmm - but by contrast drupal form api gives you an array of what will be presented on the form (fields & details) & you can adjust it at that point - without 'caring' too much about how it gets assigned to the form (themer can care if they want)

CiviCRM Community Forums (archive)

News:

Author Topic: De-quickforming or Quick deforming QuickForm (Read 910 times)

Eileen

De-quickforming or Quick deforming QuickForm

xavier

Re: De-quickforming or Quick deforming QuickForm

Eileen

Re: De-quickforming or Quick deforming QuickForm