Controlled Field Wrappers

[hutch]

It looks as though you are assuming a labeled input field when a new field type is defined and implemented by adding a new render-field method. This means you can't introduce a new field type similar to a heading, or some regular HTML.

It looks as though you're using sets containing field types to make decisions about lots of things, not just wrapping format, e.g. you're using a set to define what field types separate field-sets.

It might be nice to name (and document) these sets, and even nicer if you could make them dynamic so we could change their contents with a binding. (I'd be able to control what kind of wrapper the new field type has, and if it separates field-sets, and more).

It might be necessary to add additional multimethods to completely control this stuff.

And it's getting complicated, but at least there's reasonable defaults.

Does that make any sense?

[jkk]

Thoughts:

1) The default renderer is just that - the default. Making a custom renderer with its own particular rules for wrapping/sectioning/etc doesn't require much code. The table renderer, for example, recognizes a :stacked field key which, combined with a nil :label, makes the field display full-width without any label. I actually use the table renderer in most of my own projects, although it does require some custom CSS to make it look nice.

2) You're right in that there's room for improvement in being able to customize the default renderer. Adding hooks of some kind is a good idea.

Perhaps some generic attributes could be distilled out and attached to fields during prep, before rendering (there's actually a prep-field multimethod). The renderer could then check those attributes to determine how to lay things out. E.g.,

• :presentational - whether the field actually collects input or is merely decorative/instructional
• :labeled - whether to display and/or allocate space for a label
• :fieldset-separator

[hutch]

Sorry, just went for a short walk and about 30 seconds in to it realised that those sets I mentioned are in the renderers not core. And so are subject to extension and I shouldn't be whinging about those things since I can easily enough do this myself.

I withdraw my question until I attempt to solve it with the tools you've already provided :-)

[jkk]

No worries, I appreciate hearing this kind of feedback. In addition to helping make the defaults better/more flexible, it will help shape the documentation - I plan on writing a guide on how to tune/extend Formative.

[jkk]

Closing this, although there may be future changes that address the issues raised.