Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support for btn input addons #25

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Support for btn input addons #25

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion lib/bh/helpers/form/base_helper.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,11 @@ def field_in_group(field, prefix, suffix)
end

def input_addon(addon)
content_tag :span, addon, class: 'input-group-addon' if addon
if addon && addon.include?('class="btn')
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't really like having to do that kind of matching, but it was the only I found getting input-group-btn to work without providing extra options. Perhaps its just better to provide an options button: true or something like that. Any suggestions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finally I got time to look at this.
I cannot think of a much better solution than what you suggest.

The Bootstrap documentation says:

Buttons in input groups are a bit different and require one extra level of nesting.
Instead of .input-group-addon, you'll need to use .input-group-btn to wrap the buttons.

My understanding is that .input-group-btn should be used only if the content is exactly a button.
So one solution would be to scan the string for a regex like %{^<button.+>.+</button>$}.
However, as you point out, the content might be a different DOM element looking like a button, for instance

<input type="submit" class="btn btn-default">

In any case, all I can think of is a regex-matching of addon, similar to what you suggest…

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I don't have a clear opinion about this yet, I'll mark this PR as "version 1.2"!

content_tag :span, addon, class: 'input-group-btn'
elsif addon
content_tag :span, addon, class: 'input-group-addon'
end
end

def input_group_container(has_addons, &block)
Expand Down
5 changes: 5 additions & 0 deletions spec/helpers/form/field_helper_spec.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,6 +56,11 @@ def self.field_helpers_to_test
it { expect(form).to match %r{<div class="input-group"><.+?><span class="input-group-addon">Jr</span></div>}m }
end

context 'given a suffix option that is a button, prints the correct addon wrapper class' do
let(:options) { {suffix: content_tag(:button, 'hey', class: 'btn btn-default')} }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the objects that can be used as prefixes or suffixes are limited, I wouldn't want to expose the generic content_tag as the way to use prefixes or suffixes that are not plain text.

For instance, right now you can write

<%= f.text_field :name, prefix: 'ok' %>

The next nice step would be

<%= f.text_field :name, prefix: icon(:ok) $>

which I expect not to be working now, not being HTML-safe (I might be wrong, I didn't check).

So for the input group button, I'd like the syntax to be

<%= f.text_field :name, suffix: button_to('Go', action: 'submit') %>

which would be easier to write (and less prone to errors) than the full content_tag. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I used content_tag is that I branched this feature from master rather than additional-components, which includes a button helper (present in #15). Completely missed the button_to helper will update #15 to use that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying this PR locally, I found a couple of things:

  1. The button_to helper I wrote is incomplete. It only works in the form where the second argument is a route, but it does not work if the second argument is options. This is similar to what happened with fields_for. So I need to fix that separately
  2. Even though the following code works, the button_to helper from ActionView adds an extra <div> around the <input type="button"> field which makes the suffix display in a weird way:
<%= f.text_field :email, suffix: button_to('Go', signin_path) %>

With the current master displays as:
screen shot 2014-09-15 at 10 58 50 am

After the current PR would display as:
screen shot 2014-09-15 at 10 59 20 am

Which a little different from the desired behavior:

screen shot 2014-09-15 at 10 59 27 am

it { expect(form).to match %r{<div class="input-group"><.+?><span class="input-group-btn"><button class="btn btn-default">hey</button></span></div>}m }
end

specify 'not given an error, does not apply has-error to the form group' do
expect(form).not_to include 'has-error'
end
Expand Down