Ryan F. wrote in post #968910:
First thank you for your quick response. This forum seems like a place
I will be able to learn some proper rails coding.
NO! NO! NO! NEVER USE GLOBAL VARIABLES FOR THIS SORT OF THING!
I have never programmed in ruby and have inherited this application to
only make a few small changes. Unfortunately the original programmer
used 50+ global variables and I really do not want to rewrite
everything.
You may not have to, but it's usually a good idea to improve the parts
you're working on.
If the original programming is this bad, I assume there is little or no
test coverage? If that's the case, then I advise getting familiar with
RSpec and Cucumber, and writing tests for anything you have to change
(so you know you're not breaking things). Then do all new development
test-first.
OK, now that I've got your attention , please explain what you're
trying to do with $gItems. There will be a more appropriate place to
put it than in a global variable; we just have to figure out what it is.
this app has a parameter file where the number of items can be changed.
Depending on the integer that is placed in the parameter file, the view
must create a table element with the appropriate number of columns
($gItems). $gItems is created in ApplicationController class the first
time someone navigates to the Auctioneer view from the
auctioneer_controller class index method. This allows each subsequent
client screen to draw a table showing the appropriate number of items.
That's dreadful -- and easy to fix. Read it from the config file as
before, but assign it to a class constant or something. See
#85 YAML Configuration File - RailsCasts for some
ideas.
I feel like my explanation is very convoluted, as is the code. let me
know if i should break it down further.
I *think* I understand...
One thing to note might be that this app is not database backed.
Then why is it using Rails in the first place, I wonder?
This
is probably why the original programmer constantly used globals.
Perhaps. The fact that the original programmer also used Hungarian
Notation and CamelCase suggests that he wasn't too familiar with Ruby
idioms at all...
Note, however, that Haml is generally a superior alternative to ERb, and
in this case it provides an easier way to do this with its %tag[object]
syntax.
thanks, I like the look of Haml and will look into it further.
Best,