Still new in my ROR walk, been busily coding on a game application as a
fruitful exercise in becoming proficient in Ruby/ROR. However, I seem to
have hit a speed bump and am befuddled over some exhibited behavior in
Cookies - on page 312 of the AWDwR book by DT and DHH, it states
that if you create a cookie by assigning a value to cookies[name], you
get a “default set of options” â?? one of which that the cookie will never
expire. Which, from my empirical experience, is patently false â?? the
cookie created has a lifetime of the browser session.
But that’s easily resolved (and probably the correct default action,
anyway), and not my dilemma.
You have a nil object when you didn’t expect it! â?? is the result
when I make changes to code in /app/models and restart WEBrick and then
subsequently exercise my controller.
Which can be remedied by adding model declarations to my controller.
That indeed repairs the problem, but presents another â?? a set of
warning: already initialized constant messages spooling out upon any
page request after the initial one, due I presume, from reloading the
model classes in a redundant fashion.
Which explains why I can add/change code to controllers and views and
view instant feedback, but when I add/change code to /app/models, I must
restart the server. But odd that the application behavior is
inconsistent, i.e., on the controller action that creates the object
(and marshals it to disk, stamping a cookie with a hashed string on the
client machine so the object can be fetched on ensuing page requests),
it works just dandy on the initial page request.
Background on the application, that I reckon I should have detailed at
the top of this post â?? no database linkage to the models (of which one
“master” object is composed of a set of attribute objects), just a
create action which creates a world state, stores it to disk (after
marshalling). Then a menu of controller actions (i.e., play game,
display stats, reset, etc.) will enact an object fetch from disk (client
machine contains a cookie with a MD5 hash that corresponds to the
marshalled object file) and fire off some method(s) of that object and
restore it back to disk (if object state is updated).
And that has me confused, because I thought, at least in development
mode, all was reloaded upon every request. Furthermore, it makes me
wonder how changes can be made to a production server, without bringing
the server down (that would be a big dissuading factor against using