joomla/joomla-platform — pull request #1684 by dongilbert (2012-11-12 03:20:22+00:00)
Title: Refactoring JFormField & Co.

After several varying discussions on the topic with @elinw and others, and some of my own frustrations, I decided to give a go at refactoing JFormField and it's sister element. The reason I did this is that a lot of times, the field specific implementation of `getInput()` would process some logic that was already completed by `JFormField`, such as deciding if an element is readonly or disabled.

Doubling up on the workload like that is never good. Now, `JFormField::setup()` does most of the heavy lifting when it comes to determining what settings are active/inactive, and the child classes simply worry about the html markup that those determinations require. This allows for broader, more expressive rulesets to determine functionality in the parent class, without having to be overly verbose in the child class. For example:

```
/**
* instead of the child class doing this
* (which is inssufficient, what if the field was disabled="disabled"?)
*/
$disabled = $this->element['disabled'] == true ? 'some html' : '';

// it now does this
$disabled = !empty($this->disabled) ? 'some html' : '';
```

I did this to make it easy to add new features. In my case, I added the `$placeholder` attribute as a protected property to `JFormFieldText` and then extended similar fields that would use said attribute from that parent class.

Also new to the mix is that each child `JFormField*` class that has it's own specific attributes now has it's own `setup()` method that handles assigning those specific attributes to the field object. See `JFormFieldTextarea` for a good example of that.

I'm not claiming this is perfect, but it does pass all the tests. And it *shouldn't* break any backwards compatibility.