I''m returning a value from the db which is true/false and I''d like to convert that to something more meaningful - how can I incorporate an if then into the inline html? I have tried if ... puts "xxx", but to no avail. Sorry, I''m a noobie and not quite got my head around this as yet or the error messages. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 1 August 2010 11:32, Dis Tec <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> I''m returning a value from the db which is true/false and I''d like to > convert that to something more meaningful - how can I incorporate an if > then into the inline html?You can use conditional checking inline, with "normal" ''if...else'' blocks: <% if @my_object.active? %> This is active <% else %> You need to activate this one <% else %> or you can use the ternary operator: <%= @my_object.active? ? "This is active" : "You need to activate this one" %> or you can use ''if'' conditions as guards: <%= "This is active" if @my_object.active? %> .... it all depends what''s best for your situation. And if you find yourself doing the same checks in a couple of places, extract that out to a helper method to keep your code DRY.> I have tried if ... puts "xxx", but to no avail.What have you tried? (what was the *exact* line of code) And what was the result that was "to no avail"? (the *exact* response - did something appear; nothing; or an error?)> Sorry, I''m a noobie and not quite got my head around this as yet or the > error messages.Try the following resource as a primer; it should help you organise your requests for help to be more likely to elucidate responses: http://catb.org/esr/faqs/smart-questions.html -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Sun, Aug 1, 2010 at 06:52, Michael Pavling <pavling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 1 August 2010 11:32, Dis Tec <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:>> I''m returning a value from the db which is true/false and I''d like to >> convert that to something more meaningful - how can I incorporate an if >> then into the inline html? > > You can use conditional checking inline, with "normal" ''if...else'' blocks: > <% if @my_object.active? %> > This is active > <% else %> > You need to activate this one > <% else %> > > or you can use the ternary operator: > <%= @my_object.active? ? "This is active" : "You need to activate > this one" %> > > or you can use ''if'' conditions as guards: > <%= "This is active" if @my_object.active? %>Though your approach will work, this looks to me like it''s probably logic that more properly belongs in the controller than the view. IMHO using something like: if @my_object.active? @activated_msg = ''This is active'' else @activated_msg = ''You need to activate this one'' end # you did mean end for the 2nd else above, yes? or @activated_msg = @my_object.active? ? ''This is active'' : ''You need to activate this one'' or @activated_msg = ''This is active'' if @my_object.active? in the controller, and then using @activated_msg in the view, would be cleaner. (BTW, note the single quotes; I haven''t verified it myself, but heard that they are at least marginally faster for constant strings (i.e., where you *can* use them), since the system won''t even *try* to look for vars that need to be interpolated. Makes sense to me.) Now back to the Original Poster. Dis Tec had also written:>> I have tried if ... puts "xxx", but to no avail.That will make it put xxx on the Ruby console, not in the output to be sent back to the HTTP client. There are two things I think you need to read up on. The first will answer your general question on how to incorporate Ruby code, including conditionals and variables, into HTML. The main technique for doing that, and the default in Rails, is ERB, which works basically like JSP. (If you''re not familiar with JSP, that''s OK, just trying to help the lightbulb turn on.) The main alternate, HAML, has also gained serious traction, but I suggest you save that for after you''re at least familiar with ERB. Before you do *any* real work with either, though, I strongly suggest you read up on MVC, the Model-View-Controller approach. It''s one of the ways to maintain "separation of concerns", a general software engineering principle. You''ll find it helps you organize your code much more cleanly and maintainably. Rails uses MVC strongly. I''m not going to go into depth on them here myself, as there are gazillions of web pages that explain them well. Rails is *highly* "opinionated" and makes a lot of assumptions. Learning those opinions and assumptions (such as, that you''re using the MVC approach), how to use them, and how to override them when absolutely necessary, will help you immensely. If you find a good tutorial site or book on Rails, it should go into depth on both of these, and a lot of other fundamentals you''ll need.> Try the following resource as a primer; it should help you organise > your requests for help to be more likely to elucidate responses: > http://catb.org/esr/faqs/smart-questions.htmlOne of my all-time faves, tho IMHO the OP didn''t do too bad a job. Fairly clear phrasing, he told us what he tried, he didn''t cop a ''tude, and the main thing he needs to know isn''t all THAT obvious, at least if he hasn''t gone thru a good complete RoR tutorial. -Dave -- Specialization is for insects. -RAH | Have Pun, Will Babble! -me Programming Blog: http://codosaur.us | Work: http://davearonson.com Leadership Blog: http://dare2xl.com | Play: http://davearonson.net * * * * * WATCH THIS SPACE * * * * * | Ruby: http://mars.groupsite.com -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Dave, I mostly second your advice here, but there are a couple of things that I disagree with. Dave Aronson wrote:> On Sun, Aug 1, 2010 at 06:52, Michael Pavling <pavling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> On 1 August 2010 11:32, Dis Tec <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: > >> >> �or you can use the ternary operator: >> � �<%= @my_object.active? ? "This is active" : "You need to activate >> this one" %> >> >> �or you can use ''if'' conditions as guards: >> � �<%= "This is active" if @my_object.active? %> > > Though your approach will work, this looks to me like it''s probably > logic that more properly belongs in the controller than the view.Perhaps. Certainly any *more* logic than this in the view is inappropriate, but I think testing the value of a simple method call in the view is OK.> IMHO using something like: > > if @my_object.active? > @activated_msg = ''This is active'' > else > @activated_msg = ''You need to activate this one'' > end # you did mean end for the 2nd else above, yes? > > or > > @activated_msg = @my_object.active? ? ''This is active'' : ''You need to > activate this one'' > > or > > @activated_msg = ''This is active'' if @my_object.active? > > in the controller, and then using @activated_msg in the view, would be > cleaner.Probably not. I tend to believe that it''s a mistake to put display text in the controller in most cases. If it were any more complicated than this, though, I''d set a flag in the model or controller so that a simple boolean value could be tested in the view. [...]> There are two things I think you need to read up on. The first will > answer your general question on how to incorporate Ruby code, > including conditionals and variables, into HTML. The main technique > for doing that, and the default in Rails, is ERB, which works > basically like JSP. (If you''re not familiar with JSP, that''s OK, just > trying to help the lightbulb turn on.) The main alternate, HAML, has > also gained serious traction, but I suggest you save that for after > you''re at least familiar with ERB.I don''t know that I''d agree. Haml (not HAML!) works basically like HTML (and therefore ERb [not ERB!]) with less typing. I see no particular reason to use ERb when Haml is available.> > Before you do *any* real work with either, though, I strongly suggest > you read up on MVC, the Model-View-Controller approach. It''s one of > the ways to maintain "separation of concerns", a general software > engineering principle. You''ll find it helps you organize your code > much more cleanly and maintainably. Rails uses MVC strongly.Agreed. The problem is that every MVC framework has a different interpretation of what MVC is. (I came to Rails from Fusebox, which has an optional MVC design pattern [which I used] that works very differently from Rails'' MVC. Cocoa MVC is different again, I believe.) [...]>> Try the following resource as a primer; it should help you organise >> your requests for help to be more likely to elucidate responses: >> http://catb.org/esr/faqs/smart-questions.html > > One of my all-time faves,And no longer mine. ESR does explain -- mostly -- how to ask smart questions, but spends IMHO far too much time saying "look, we don''t care about being nice or helpful. Don''t expect civility or help when you ask questions. Just fuck off and hope the gurus throw you a bone." That''s not how I want the communities I''m part of to work. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Aug 2, 2010 at 10:58, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Dave, I mostly second your advice here, but there are a couple of things > that I disagree with....> any *more* logic than this in the view is > inappropriate, but I think testing the value of a simple method call in > the view is OK.Fair enough. One needn''t be a purist. I was just trying to point the OP to the right path, even if he can stray from it.>> IMHO using something like:...>> @activated_msg = ''This is active'' if @my_object.active? >> >> in the controller, and then using @activated_msg in the view, would be >> cleaner. > > Probably not. I tend to believe that it''s a mistake to put display text > in the controller in most cases.Hmmmm. Now that I think about that, you''re probably right, it would more properly belong in the view. But before making a habit of it, I''d like to give it some more thought. What arguments (other than MVC purity) can you (or anyone else) come up with for either side? On the controller-side, it means fewer decisions being made in the view, but IMHO that''s a pretty weak argument.> If it were any more complicated than > this, though, I''d set a flag in the model or controller so that a simple > boolean value could be tested in the view.Yes, that''s sort of the main point I was getting at before. Looking at the object''s activation state, goes in the controller. Passing in a simple @object_active? boolean, though, could be perfectly fair game for the view.> I don''t know that I''d agree. Haml (not HAML!) works basically like HTML > (and therefore ERb [not ERB!]) with less typing. I see no particular > reason to use ERb when Haml is available.Use, perhaps not. Be familiar with, yes, so he can read a lot more examples. Sorry about the "CaseS BeIng WRoNG", I''m still somewhat of a RubyNuby myself, so some of these things aren''t quite in my fingers'' muscle memory yet!> The problem is that every MVC framework has a different > interpretation of what MVC is.Ah, well, that''s the great thing about standards, innit? So many to choose from.... ;-)> And no longer mine. ESR does explain -- mostly -- how to ask smart > questions, but spends IMHO far too much time saying "look, we don''t care > about being nice or helpful. Don''t expect civility or help when you ask > questions. Just fuck off and hope the gurus throw you a bone." That''s > not how I want the communities I''m part of to work.That''s just esr being esr. I s''pose it comes off that way to people not used to him. If you can get past that stuff, and follow the basic advice, it''s quite useful. I paraphrased it in a blog post once as: * Try to solve it yourself first. The essay details several information sources to try. * Ask the right person or group. * Communicate well, including: o Use correct grammar, spelling, punctuation, etc.; don''t m4Ke 7h33 07h4R P3r51n 5p3Nd 4 !07 uv h1z 7yM3 f!9uR1nG oU7 wU7 u m33N! o Get to the point. Preferably as early as the Subject line, if asking by email. o Be specific about the problem or question, and what kind of help you''re looking for. o Give all the data you have. o But still be concise. * Say what you already tried, and why that didn''t satisfy you. * Above all, be nice about it! Don''t assume that any problem you''re having, is his fault, or even not yours. Don''t expect an instant solution on a silver platter. You''re probably not paying the person who''s helping, so be grateful that they''re putting forth any effort at all for you. (Currently at http://dare2xl.braveblog.com/ and eventually to be moved to http://dare2xl.com/.) -Dave -- Specialization is for insects. -RAH | Have Pun, Will Babble! -me Programming Blog: http://codosaur.us | Work: http://davearonson.com Leadership Blog: http://dare2xl.com | Play: http://davearonson.net * * * * * WATCH THIS SPACE * * * * * | Ruby: http://mars.groupsite.com -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Thanks for the advice guys... I appreciate it might have been pretty ambiguous. I guess I am trying to avoid the mix of logic and text but appreciate that in some cases it might be fine to just go ahead and do this. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Dave Aronson wrote:> On Mon, Aug 2, 2010 at 10:58, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> > wrote: >> Dave, I mostly second your advice here, but there are a couple of things >> that I disagree with. > ... >> any *more* logic than this in the view is >> inappropriate, but I think testing the value of a simple method call in >> the view is OK. > > Fair enough. One needn''t be a purist. I was just trying to point the > OP to the right path, even if he can stray from it.I don''t think this is a question of purism. I think that it''s not impure MVC to check a boolean flag in the view -- in fact, I think that''s exactly what an MVC-style view should be doing. Do you disagree?> >>> IMHO using something like: > ... >>> @activated_msg = ''This is active'' if @my_object.active? >>> >>> in the controller, and then using @activated_msg in the view, would be >>> cleaner. >> >> Probably not. �I tend to believe that it''s a mistake to put display text >> in the controller in most cases. > > Hmmmm. Now that I think about that, you''re probably right, it would > more properly belong in the view. But before making a habit of it, > I''d like to give it some more thought. What arguments (other than MVC > purity) can you (or anyone else) come up with for either side? On the > controller-side, it means fewer decisions being made in the view, but > IMHO that''s a pretty weak argument.Actually, that''s a pretty strong argument. MVC purity rules all in some sense. But I also like not having to deal with I18N in the controller, and I like knowing that the view does (essentially) all the rendering of anything visible. The controller should deal with logic flow, not display details (view) or logic implementation (model).> >>�If it were any more complicated than >> this, though, I''d set a flag in the model or controller so that a simple >> boolean value could be tested in the view. > > Yes, that''s sort of the main point I was getting at before. Looking > at the object''s activation state, goes in the controller.It doesn''t need to. If the model already has a simple active? flag on it, there''s no reason for the controller to touch it.> Passing in > a simple @object_active? boolean, though, could be perfectly fair game > for the view.Right.> >> I don''t know that I''d agree. �Haml (not HAML!) works basically like HTML >> (and therefore ERb [not ERB!]) with less typing. �I see no particular >> reason to use ERb when Haml is available. > > Use, perhaps not. Be familiar with, yes, so he can read a lot more > examples.True.> Sorry about the "CaseS BeIng WRoNG", I''m still somewhat of > a RubyNuby myself, so some of these things aren''t quite in my fingers'' > muscle memory yet!Understood! :D> >> The problem is that every MVC framework has a different >> interpretation of what MVC is. > > Ah, well, that''s the great thing about standards, innit? So many to > choose from.... ;-)MVC isn''t a standard. It''s a philosophy, and perhaps a "metapattern", that''s been differently interpreted over the years. The usual understanding of it today -- at least among Rails developers -- seems to be quite perverted from what Trygve Reenskaug originally defined.> >> And no longer mine. �ESR does explain -- mostly -- how to ask smart >> questions, but spends IMHO far too much time saying "look, we don''t care >> about being nice or helpful. �Don''t expect civility or help when you ask >> questions. �Just fuck off and hope the gurus throw you a bone." �That''s >> not how I want the communities I''m part of to work. > > That''s just esr being esr. I s''pose it comes off that way to people > not used to him.I don''t care how big his name is. If he''s giving mean-spirited advice, I''m going to call him on it. (For the record, I don''t think it is just "ESR being ESR". I find many of his other articles quite well written and useful. I think it''s a guru thinking that it''s all right to be uncivil if you know enough -- an opinion I do not really subscribe to.)> If you can get past that stuff, and follow the basic > advice, it''s quite useful.Parts of it, yes. I find the "you are a poor supplicant who must hope the gurus throw you a bone" attitude very *unuseful* indeed. " I paraphrased it in a blog post once as:> > * Try to solve it yourself first. The essay details several > information sources to try. > > * Ask the right person or group. > > * Communicate well, including: > o Use correct grammar, spelling, punctuation, etc.; don''t > m4Ke 7h33 07h4R P3r51n 5p3Nd 4 !07 uv h1z 7yM3 f!9uR1nG oU7 wU7 u > m33N! > o Get to the point. Preferably as early as the Subject line, > if asking by email. > o Be specific about the problem or question, and what kind > of help you''re looking for. > o Give all the data you have. > o But still be concise. > > * Say what you already tried, and why that didn''t satisfy you.Yes, those are among the points I agree with.> > * Above all, be nice about it!I agree with that too. A pity he doesn''t follow his own advice. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 2 August 2010 15:34, Dave Aronson <googlegroups2dave-BRiZGj7G2yRXqviUI+FSNg@public.gmane.org> wrote:> On Sun, Aug 1, 2010 at 06:52, Michael Pavling <pavling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> You can use conditional checking inline, with "normal" ''if...else'' blocks: > > Though your approach will work, this looks to me like it''s probably > logic that more properly belongs in the controller than the view. > IMHO using something like: > > if @my_object.active? > @activated_msg = ''This is active'' > else > @activated_msg = ''You need to activate this one'' > end # you did mean end for the 2nd else above, yes?I know that you and Marnen have covered this, so I won''t go over it too much, but I would add my voice to the "it should NOT be in the controller" camp. I may reuse the same views from several controller actions, and I don''t want to have to duplicate the variable-setting in lots of places. The "I don''t want view text in my controllers" has already been covered. I also don''t see the value in setting instance variables to store values that are accessible on the model that''s being passed to the view. Also, the conditional block might be being operated on an element of a collection, and I *really* don''t want to iterate all my foos to see whether each has bar set true or not (I''m sorry for using "active" earlier, as it seemed to get the focus of the consideration), and then store that result in another hash... etc.> (BTW, note the single quotes; I haven''t verified it myself, but heard > that they are at least marginally faster for constant strings (i.e., > where you *can* use them), since the system won''t even *try* to look > for vars that need to be interpolated. Makes sense to me.)They are, to all reports, marginally faster, but I still use double quotes everywhere for ease and consistency . It strikes me as premature optimisation to default to single quotes for the minuscule time advantage (and I rarely set strings to variables anyway; generally following the "extract variable" refactoring pattern instead and call a method to return them - even slower! But easier to maintain ;-) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Michael Pavling wrote:> On 2 August 2010 15:34, Dave Aronson <googlegroups2dave-BRiZGj7G2yRXqviUI+FSNg@public.gmane.org> > wrote: >> �@activated_msg = ''You need to activate this one'' >> end �# you did mean end for the 2nd else above, yes? > > I know that you and Marnen have covered this, so I won''t go over it > too much, but I would add my voice to the "it should NOT be in the > controller" camp. I may reuse the same views from several controller > actions, and I don''t want to have to duplicate the variable-setting in > lots of places.I, too, have been giving more consideration to unnecessarily using instance variables. A few years ago, I used them all the time, but the more I use partials, the more I prefer to pass variables in :locals.> > The "I don''t want view text in my controllers" has already been covered. > > I also don''t see the value in setting instance variables to store > values that are accessible on the model that''s being passed to the > view.+1>> (BTW, note the single quotes; I haven''t verified it myself, but heard >> that they are at least marginally faster for constant strings (i.e., >> where you *can* use them), since the system won''t even *try* to look >> for vars that need to be interpolated. �Makes sense to me.) > > They are, to all reports, marginally faster, but I still use double > quotes everywhere for ease and consistency . It strikes me as > premature optimisation to default to single quotes for the minuscule > time advantage (and I rarely set strings to variables anyway; > generally following the "extract variable" refactoring pattern instead > and call a method to return them - even slower! But easier to maintain > ;-)This is likely one of those "matter of personal preference" things. I make it a point to use double quotes *only* when I''m interpolating. It started out as "premature optimization", but I also find that when scanning code, I can automatically ignore one or the other depending on what I''m scanning for. If I''m looking for a particular piece of interpolation, I can ignore everything surrounded by single quotes. [ Or, I could just use Find ;) ]. And I suppose one could make the argument that using single quotes except when you need double will save you from having to press the SHIFT key, though I wouldn''t be one of them. I used to work with a guy (Delphi developers at the time) who never capitalized anything he didn''t have to. I once asked him why and he said it was because he didn''t want to waste the keystroke of pressing SHIFT. Different (?:key)?strokes for different folks, I guess. Peace, Phillip -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.