Proposal for handling forms in backend of Fork CMS a bit different.

1. Fofo’s
2011-08-19

2. What? Why? Huh?
‣ Fork Forms
‣ Ge kunt er “Phopho” van maken, c’est très PHP.
‣ Veel dichter bij “foef” dan menig mannelijke developer.

3. Slides suck, show code

4. Backend forms in Fork

5. Backend forms in Fork
‣ Known way of doing things
‣ $this->frm->addText() ... etc typing is a drag, so we
copypaste... (kind of a naive passive code generation)
‣ Maintainability/DRY violation (adding/changing fields)
‣ Not that oopie...
‣ SOC: too much responsibility in action (ie. controller)

6. Add field (solely in action / template edits):
‣ add.php (in loadForm() and validateForm())
‣ edit.php (in loadForm() and validateForm())
‣ add.tpl
‣ edit.tpl
=> 6 different code units

7. Extract form from action

8. Extract form from action
‣ Introduce class hierarchy: add > base (BEForm) < edit
‣ Initial SLOC increase (sloccount counts ‘{‘ and ‘}’), but
SLOC in actions shrinks (“thin controller”)
‣ SOC/modularity: Action does action things, Form does
form things: brain likes, testability increases.
‣ More DRY => less pain

9. Add field (solely in action / template edits):
‣ forms.php (in loadFields())
‣ form_fields.tpl
=> in 2 different code units, but it should be 1, so ...

10. What’s next?

11. What’s next?
‣ Move stuff to the model (“thin controller, fat model”),
actions will become parametrizable thin.
‣ More DRY/SPOT, see django models.py fi.
‣ BackendForm::__toString(), no field prefix in tpl.
‣ ORM (not a light step)
‣ ... ?

12. @dubgeiser
(No warranty intended or implied)
github.com/dubgeiser