content_tag vs tag

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?

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

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

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:

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

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?

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"

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

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

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.

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

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 :).

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