content_tag vs tag

rubyonrails-core
1

I couldn't find anyone mention this in the group archives, so I'll bring it up.

Aside from backward compatability, is there any reason content_tag and tag should be two different methods? Can't you infer their different outputs by the parameters you pass?

2

content_tag requires content be passed to it (which it should), but if you use one method, you would have to make the content parameter optional when using tags such as br or hr. If you don't make the content parameter optional then a method such as tag('br', '') would not be as clean and also give the impression that a br tag can have content which it should not.

So no, I'd say you cannot infer the outputs from the parameters passed and the current two methods should stay put.

Andrew

3

the content parameter of content_tag is optional. content_tag(:br) produces 

<br></br>

so, aside from backwards compatability, I see no reason why you couldn’t have:

  def tag(name, options = nil, open = false)

    content_tag(name, nil, options)

  end

and possibly modify content_tag_string as well:

    def content_tag_string(name, content, options)

      tag_options = tag_options(options) if options

      if content.nil?

        "<#{name}#{tag_options} />"

      else

        "<#{name}#{tag_options}>#{content}</#{name}>"

      end

    end

lawrence

4

I don't see what's wrong with making the content parameter optional, or maybe I don't understand what you're saying. If you leave the content blank, make it a self-closing tag.

<code>

tag 'br' # => <br /> tag 'br', '' # => <br><br />

</code>

Andrew Kaspick wrote:

5

My apologies... the content parameter is optional. I retract my initial remark and agree with what you had said. Sorry about that. :wink:

6

So, there doesn't seem to be any compelling design reason to have both content_tag and tag.

Any objections to deprecating content_tag and merging its functionality with tag?

7

So how do you make a div with options? I don't want to have to pass an empty string, that seems weak:

content_tag :div, '', :class => "something"

8

That example obviously doesn't make sense, this is what I meant:

tag :hr, '', :style => "padding: 10px"

9

tag :hr, :style => "padding: 10px"

If you wanted <hr style="padding: 10px"></hr>, for whatever reason, you'd pass that empty string as the second param.

10

You can take a look hor Markaby does that kind of thing. The only problem is shoehorning all of that into erb. Basically, there can be the following course of action

tag(*args) -> if arg1 and arg0 are stringables we do content_tag, else we do tag, options go downstream, block is permitted if no string is passed

11

tag(*args) -> if arg1 and arg0 are stringables we do content_tag, else we do tag, options go downstream, block is permitted if no string is passed

That sounds neat, send me a patch and I'll get it in :).

12

Wait I had a Camping sprint tonight so need some sleep

there is a dusty patch of mine which implements tag with a block attribute but I should take a look at it’s ERB interaction

the same old return-versus-concat stupidity