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? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 On 9/18/07, Sandofsky <sandofsky@gmail.com> wrote:> > 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? > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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> 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 > > On 9/18/07, Sandofsky <sandofsky@gmail.com> wrote: > >> 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? >> >> >> > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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:> 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 > > On 9/18/07, Sandofsky <sandofsky@gmail.com> wrote: > > > > 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? > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
My apologies... the content parameter is optional. I retract my initial remark and agree with what you had said. Sorry about that. ;) On 9/18/07, Sandofsky <sandofsky@gmail.com> wrote:> > 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: > > 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 > > > > On 9/18/07, Sandofsky <sandofsky@gmail.com> wrote: > > > > > > 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? > > > > > > > > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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? On Sep 18, 2:28 pm, Sandofsky <sandof...@gmail.com> wrote:> 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?--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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" On Sep 21, 5:28 pm, Sandofsky <sandof...@gmail.com> wrote:> 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? > > On Sep 18, 2:28 pm, Sandofsky <sandof...@gmail.com> wrote: > > > 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?--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
That example obviously doesn''t make sense, this is what I meant: tag :hr, '''', :style => "padding: 10px" On Sep 21, 5:28 pm, Sandofsky <sandof...@gmail.com> wrote:> 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? > > On Sep 18, 2:28 pm, Sandofsky <sandof...@gmail.com> wrote: > > > 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?--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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. On Sep 21, 3:34 pm, DHH <david.heineme...@gmail.com> wrote:> That example obviously doesn''t make sense, this is what I meant: > > tag :hr, '''', :style => "padding: 10px" > > On Sep 21, 5:28 pm, Sandofsky <sandof...@gmail.com> wrote:> 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? > > > On Sep 18, 2:28 pm, Sandofsky <sandof...@gmail.com> wrote: > > > > 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?--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 22-sep-2007, at 1:09, Sandofsky wrote:> 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 -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> 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 passedThat sounds neat, send me a patch and I''ll get it in :). -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Sep 23, 2007, at 2:20 AM, Michael Koziarski wrote:> >> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---