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.
On 1 August 2010 11:32, Dis T. [email protected] 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
On Sun, Aug 1, 2010 at 06:52, Michael P. [email protected] wrote:
On 1 August 2010 11:32, Dis T. [email protected] 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.
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 T. 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:
How To Ask Questions The Smart Way
One 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
Dave, I mostly second your advice here, but there are a couple of things
that I disagree with.
Dave A. wrote:
On Sun, Aug 1, 2010 at 06:52, Michael P. [email protected] wrote:
On 1 August 2010 11:32, Dis T. [email protected] 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:
How To Ask Questions The Smart WayOne 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.
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Mon, Aug 2, 2010 at 10:58, Marnen Laibow-Koser [email protected]
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 Dare2XL: Dare to Excel!)
-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
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.
Dave A. wrote:
On Mon, Aug 2, 2010 at 10:58, Marnen Laibow-Koser [email protected]
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! 
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 severalinformation sources to try.
* Ask the right person or group. * Communicate well, including: o Use correct grammar, spelling, punctuation, etc.; don'tm4Ke 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.
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On 2 August 2010 15:34, Dave A. [email protected]
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.
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
Michael P. wrote:
On 2 August 2010 15:34, Dave A. [email protected]
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs