This is very sweet and totally useless. For example, I want to see the
session variable, the cookies variable and so on. These names are unknown.
I think I guess that the things that are available depend on where you put
the breakpoint() call. I’ve tried a couple of different spots and “session”
is unknown.
Here’s a general pointer on mailing list manners: If your lack of
knowledge limits you from seeing the full potential of a feature or to
use it as intended, you can’t resolve either by lashing out. Your
request is all venom, no sweet, so no wonder you are not seeing many
bites by the knowledgable.
Instead, let’s assume that you had started your request with:
“I’ve read in the Agile book about how useful script/console can be
for introspection. I’ve figured out how to use these powers for model
manipulation, but I’d love to use it for controller too, specifically
sessions and cookies. Can anyone help me learn how?”
Sorry for the snarkiness but there was a particular analysis (criticism)
I was trying to
express. The writer of
“You can inspect variables, set values, add other breakpoints, and
generally have a good
time”
was himself having a good time at the expense of precision. My point
was (or should have
been) that the variables and values and breakpoints need to be
explained, with examples.
Or with reference to a place that has more examples.
The console environment is part of Rails and is barely defined. For
example, will the
thread and process model imposed by differing web server environments
impact the debugging
tools and the way they work? I’m asking about webbrick vs lighty vs
apache-fcgi. It
would make sense that different threading and process models would be
approached
differently. And what happens when I start more than one breakpointer
waiting for a
connection – is there a scheme to parcel them out among threads? This
all needs to be
documented or at least referenced.
As long as I’m complaining, I have a question: How do you search the
Rails api docs? Do
you use google?
Thanks for all your work – you’ve done a lot. And my request wasn’t
all venom. I
actually didn’t think of it as venom. After all, the sentence in
question is truly sweet.
“Completely useless” was just an exaggeration, not a fact. And I’m
sorry for those I’ve
offended.
I’ve figured out how to use script/console for model manipulation, but
I’d love to use it
for controller too, specifically sessions and cookies. Can anyone help
me learn how?
Also, do you have reference to info on the impact of threading models
and web server
differences on the debugging process? The various thread/process models
have to have
impacted the design of rails itself and so I guess that info is locked
away in somebody’s
head or somebody’s document.
Also, do any of you have a technology that can prevent me from
developing a bad mood after
a frustrating debug session? I’d like to be charming ALL the time.
I’ve figured out how to use script/console for model manipulation,
but I’d love to use it
for controller too, specifically sessions and cookies. Can anyone
help me learn how?
Yes, the Agile Web D. with Rails book is going to explain
all this and so much more.
As far as the limits of the console goes, I think it’s generally just
used as a
“out-of-container” ad hoc testing tool… as in you can start up
script/console to ask
questions of your model/db. But for doing anything with controllers and
the
request/response cycle, you need to use breakpointer.
I have that book but don’t find the section that describes
accessing sessions and cookies
in the console. Can you give me a location?
You cannot get what you want via script/console.
You need to put a ‘breakpoint’ statement into your code where the
variables and/or methods
you want to inspect are.
Then you need to run script/breakpointer.
Then you need to exercise that code, either via a unit or functional
test, or a browser.
When your code hits that spot, the breakpointer will come alive and
give you something
very similar (exactly the same?) as the console, but with the state
of your executing
code.
As a shortcut, you can call breakpoint with an object to inspect the
moment the breakpoint
occurs, saving you a step:
breakpoint session
In a controller action method, for instance, will dump the contents
of session to the
breakpointer the moment the code is executed.
Once you have the command line, you can type ruby commands, and
they’ll execute precisely
as though they were in your source file, except that you get to
visually inspect the
return values.