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.

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

Support for btn input addons #25

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

Conversation

buren
Copy link
Contributor

@buren buren commented Sep 14, 2014

@@ -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"!

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling 1094c07 on buren:input-button-addons into d40656c on Fullscreen:master.

@@ -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

@buren buren mentioned this pull request Sep 14, 2014
43 tasks
@claudiofullscreen
Copy link
Contributor

Looking at the code, I realize that we might actually want a simple button helper that does not mess up with button_to.

<%= button 'Go', context: :success %>

would simply transform into

<button class="btn btn-success" type="button">Go</button>

Initially I thought we could just use button_to in every occasion, but I realize there might be cases where users simply want buttons not tied to a form.

Once the button helper is merged, then the PR above becomes much easier.

@claudiofullscreen
Copy link
Contributor

Also, ActionView already provides a similar helper called button_tag, so might look into that as well.

@buren
Copy link
Contributor Author

buren commented Sep 15, 2014

That is the exact thing I've done in #15 in button_group_helper :)
On 15 Sep 2014 20:34, "claudiofullscreen" notifications@github.com wrote:

Looking at the code, I realize that we might actually want a simple button
helper that does not mess up with button_to.

<%= button 'Go', context: :success %>

would simply transform into

Go

Initially I thought we could just use button_to in every occasion, but I
realize there might be cases where users simply want buttons not tied to a
form.

Once the button helper is merged, then the PR above becomes much easier.


Reply to this email directly or view it on GitHub
#25 (comment).

@claudiofullscreen
Copy link
Contributor

Yes! Taking a look at that now.

@claudiofullscreen claudiofullscreen added this to the 1.2 milestone Sep 20, 2014
@buren
Copy link
Contributor Author

buren commented Sep 26, 2014

@claudiofullscreen status? let me know if I can do anything

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants