Missing simple-form niceities

[fran-worley]

1. ~~Error Notification Produce an error notification at the top of the form if there are any errors via f.error_notification.~~
2. ~~Hints These are built into both bootstrap and foundation and should be supported in Formular. You should be able to either pass a hint option to an input, or call a hint via f.hint 'hint text'~~
3. ~~Independent Errors You should be able to render an error for an attribute directly by calling f.error :attribute_name. Very useful for hidden fields~~
4. ~~Independent Labels You should be able to render a label independent of an input (e.g. f.label :attribute_name).~~
5. Required fields Add an indication of whether a field is required (do we hook into reform?).
6. Label text Can we guess a label text from the attribute name or is this a bit too magical? I was planning on something as simple as replace '_' with ' ' and making the first letter upper cased. Though I guess you've got i18n to consider. Most HTML specs now say that for accessibility you should include a label even if it's not visible. This would encourage people to do so and avoid lots of unnecessary call like f.input :title, label: 'Title'. You can already pass in label: false to ensure that a label isn't rendered. Maybe a middle ground would be to make this a configurable option?
7. i18n support If we look to add 1 or 6 we should also enable translations.
8. ~~Collection helpers Currently we require nested arrays with value first and label last. - Now configurable via label_method and value_method Selects could also do with an include_blank/ prompt option.~~

[blelump]

Hi @fran-worley ,

got some spare time this Saturday afternoon so I'm back in Formular things. I think 5. is somewhat covered in #16 and the proposed solution sounds good (having multiple element sets). In such case it's more about attributes organization in concrete semi–abstract types to be able to extend such types to provide its specialized version for particular builder (if necessary).

Re labeling and I18n , what do you think about the possibility of having smth like label provider, where one can define whatever way the labels are built (or fetched)? Such label provider may be a part of form builder and hence it'd be easy to configure. Besides, it implies (at least to me :smile: ) that fetching label name from whatever.nested.form.labels and then field_name might always be changed within custom label provider since it'd be a part of form builder. Well, it'd be even customized per builder.

Update:

Re: first paragaph. Well, while thinking about attributes in particular form objects, we can think of about traits as well. A trait provides concrete behaviour for given type, eg. Reviewable, Requireable etc. The main problem I've encountered with such approach so far is that it's diffcult to apply DSL for module, eg. set_attribute usage. I know I can use Declarative::Heritage::DSL , but I kinda don't like this approach as it's pretty magical. Besides it doesn't help with trait extensions. So I've ended up with smth like:

    module Reviewable
      def self.included(base)
        base.extend Label
        base.extend CommentButton
        base.include LabelColumn
        base.include InputColumn

        base.class_eval do
          set_default :class, %w(blah)
        end
      end
    end

[fran-worley]

Good to hear from you @blelump. I'm intending to do an initial RC release this week so these changes probably won't be included.

5. I'll have another look at my ponderings on the subject and have another look. I do like your suggestion of traits, though I really don't want to end up building FactoryGirl::Formular! 😉

6. I was considering handling labels in the same way as errors. You could pass a labels hash or an object which responds to your attribute names as methods and returns the labels. You can always override per input if you need but that would enable you to handle label generation yourself, on a per builder/ per form basis.

[fran-worley]

@blelump you should just be able to include include Formular::Element::Module and then you can just treat a module the same as a Element Class.

It works in the same way as Reform modules.

[blelump]

@fran-worley ,

good news!

ad 5: What do you mean by saying FactoryGirl::Formular?

ad. 6: Nice idea. I think most ppl will just use I18n as a label provider, so that's probably most desired. I proposed a label provider, probably because of my personal habits :smile: . I used to group things in I18n by their purpose and form labels usually land in e.g en.label key.

And yeah, I know I can use the Formular::Element::Module, but imagine a trait that consists of other traits. All of them need to include Formular::Element::Module then. Something like a trait may be sometimes a better approach than inheritance (I don't know for sure, just my personal reflections), because of forms nature :smile: , e.g. I have a form that's a reviewable form , where you can add a comment for any form field. The same form becomes read only form once it's reviewed (inputs become p tags). Here I can distuinguish form purpose by its type (reviewable form and static form) and for any of them add an element that exposes its behaviour by traits, eg:

    class Select < elements[:select]
      include Reviewable
      include Requireable
    end