bindMapper

Goals and Background

For data-oriented display and input forms, right now there are two choices within the Mapper framework: CRUDify and custom snippets.

CRUDify provides a lot out of the box and can then be tweaked in a few places. But I’ve found it to be best for Prototyping and a few administrative functions where a precise design is not important and workflows are simple. When trying to use it more intensively I found myself having to rely heavily on the CRUDify source code for documentation. A typical white-box framework situation.

The other alternative are custom snippets. They allow every conceivable HTML to be produced, and have no dependence on the Mapper library themselves. I used this approach a lot, but ended up with a lot of boilerplate code; e.g. if you add a field to a Mapper class, you have to also add it in the edit and view template, and in the bind statements in each Snippet.

The code really threatened to become repetitive and complicated when I needed to integrate further aspects:

• Dealing with empty field values (e.g. hide the field altogether with its caption)
• Displaying field errors/warnings

Finally, with the classic bind, a snippet only lends itself to reuse in different templates in a limited way. All the bind parameters are created before making the call to bind, which means that lookups etc. have to be performed even if the corresponding tag is not bound in the current template.

Binding Deluxe – binding a single Mapper instance with bindMapper

With the MBindHelper trait and object provided here, you can now write more concise templates and Snippets that have a lot of standard built-in features and only do the work that is actually required in the current context.