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

Parametrize break sequence for word_wrap on ActionView Text Helpers #21086

Merged
merged 1 commit into from
Aug 11, 2015

Conversation

bukue
Copy link

@bukue bukue commented Jul 31, 2015

Sometimes you need a specific break sequence while using word wrap and as today the only option we have is "\n" and is hardcoded.

With this change you will be able to specify any break sequence ("\r\n" for example) as an option.

@meinac
Copy link
Contributor

meinac commented Jul 31, 2015

@bukue could you please add documentation about it?

@bukue
Copy link
Author

bukue commented Jul 31, 2015

@meinac done!

@@ -366,6 +366,10 @@ def test_word_wrap_does_not_modify_the_options_hash
assert_equal options, passed_options
end

def test_word_wrap_with_custom_break_sequence
assert_equal("1234567890\r\n1234567890\r\n1234567890", word_wrap("1234567890 "*3, :line_width => 2, :break_sequence => "\r\n"))
Copy link
Contributor

Choose a reason for hiding this comment

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

New hash syntax please. And add spaces around *.

@bukue
Copy link
Author

bukue commented Aug 3, 2015

@meinac @kaspth I just submitted the changes that you guys asked. This is ready for another review.

@kaspth
Copy link
Contributor

kaspth commented Aug 3, 2015

@bukue doing great. Now we just need you to squash your commits down to one 😁

@bukue bukue force-pushed the add_break_sequence_option_to_word_wrap branch from db8cac8 to 2bf9b54 Compare August 3, 2015 22:41
@bukue
Copy link
Author

bukue commented Aug 3, 2015

@kaspth done!

@matthewd
Copy link
Member

matthewd commented Aug 3, 2015

I'm a bit dubious as to whether we actually want this... but that notwithstanding, shouldn't the split change too?

@bukue
Copy link
Author

bukue commented Aug 3, 2015

@matthewd Why are you dubious?

The main reason to split with "\n" is to split by lines. I see how it would be useful to split it by "\r\n" or any other sequence that helps defining a line. Unless somebody else considers it not useful, I will gladly implement it.

@bukue
Copy link
Author

bukue commented Aug 3, 2015

@matthewd added the changes you suggested

@matthewd
Copy link
Member

matthewd commented Aug 4, 2015

Why would your line_splitter and break_sequence differ? My concern was that you'd seemingly-arbitrarily chosen to replace some of the instances of "\n" in the method with a parameter -- not that we hadn't added enough parameters.

What does this offer over word_wrap(...).gsub("\n", "\r\n") ?

If I use a break_sequence of "...\nand then, ", how does that interact with the line width? I can obviously see the answer... but is that going to be what callers would expect, and/or find most useful?

"Great!, this is just what I need... I'll wrap on "<br>\n".html_safe"

@bukue
Copy link
Author

bukue commented Aug 4, 2015

Yeah, you can totally have the same result doing word_wrap(...).gsub("\n", "\r\n"). Actually, this PR started because we were doing the exact same thing at work because we needed the end of lines to be indicated with "\r\n".

I see your point, although I feel this changes give you more legibility and flexibility. Let's see what the other guys think.

@bukue
Copy link
Author

bukue commented Aug 6, 2015

@kaspth @meinac what do you guys think?

@kaspth
Copy link
Contributor

kaspth commented Aug 8, 2015

This feels like way too much code for me for something that can be done with gsub ¯_(ツ)_/¯

@meinac
Copy link
Contributor

meinac commented Aug 8, 2015

I agree with @kaspth. If you are doing this many times in your application then I recommend you to create a method which does what do you want for your application.

@bukue
Copy link
Author

bukue commented Aug 8, 2015

This approach is cheaper since you don't have to transverse your string twice like you would do using gsub. Also, all I am doing is parametrizing things that otherwise would be hardcoded.

This would be my first commit to the rails repository so I might be going to far with my changes. So if you guys believe this change is too much I am happy to roll it back to just parametrizing the line break.

What do you guys think?

def word_wrap(text, options = {})
line_width = options.fetch(:line_width, 80)
line_splitter = options.fetch(:line_splitter, "\n")
Copy link
Contributor

Choose a reason for hiding this comment

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

Lets take out the line splitter.

@bukue bukue force-pushed the add_break_sequence_option_to_word_wrap branch from 4854e44 to c10ddae Compare August 11, 2015 21:02
…d as today the only option we have is "\n" and is hardcoded.

With this change you will be able to specify any break sequence ("\r\n" for example) as an option.

adding proper documentation for break_sequence in ActionView::Helpers::TextHelper.word_wrap

adding some more documentation for word_wrap custom break sequence and making sure we use new hash syntax
@bukue bukue force-pushed the add_break_sequence_option_to_word_wrap branch from c10ddae to cf93c6a Compare August 11, 2015 21:15
@bukue
Copy link
Author

bukue commented Aug 11, 2015

@kaspth All done!

kaspth added a commit that referenced this pull request Aug 11, 2015
…d_wrap

Parametrize break sequence for word_wrap on ActionView Text Helpers
@kaspth kaspth merged commit 73c9e6a into rails:master Aug 11, 2015
@kaspth
Copy link
Contributor

kaspth commented Aug 11, 2015

Thanks

jonathanhefner added a commit to jonathanhefner/rails that referenced this pull request Sep 5, 2022
`word_wrap` was changed to use kwargs in rails#21086, so it cannot modify the
options hash.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants