No problem. The error that is reported there is less than totally
helpful in understanding why the error occured. That is on the todo
list to fix.
IS there an easy way of finding where the Ruby code is incorrect? I
am finding that I am copying the .iwa file to a .rb file, editing it
to remove the odd bits, then running against Ruby. I am sure you
have a more efficient way ...[/QUOTE]
Sure. The ruby code is evaluated by Ruby, and any Exceptions that are
thrown are dumped into the logfile with a complete backtrace. So all you
should have to do is to check the log file for the iowa app and it should be
clear. You'll see something like this:
[INFO] iowa_log @ 2004-08-20 06:53:19 :: Loading
template /usr/local/htdocs/xxxx.xxxx.com/iowa/AddInventoryByManufacturer.html
[INFO] iowa_log @ 2004-08-20 06:53:19 :: Creating namespace
Iowa::Application::Content_Classes
[INFO] iowa_log @ 2004-08-20 06:53:19 :: There was an error while
processing /usr/local/htdocs/xxxx.xxxx.com/iowa/AddInventoryByManufacturer.ht
ml:
(eval):1:in `module_eval': compile error
(eval):20: parse error
And following that will be a full backtrace.
I am completely open to suggestions on improving what is trapped in the
logfile -- either the actual information or the format of the information,
but what is there right now should point you right to the offending line.
In the above, the .iwa file for the AddInventoryByManufacturer, line 20, had
the error in it.
Your log file's location is controlled in the .cnf file. For example, in
the webrick demo in the source, there is this:
logging:
basedir: ../log
This says that the log(s) will be written in a directory ../log relative to
the iowa directory.
I am working on three things to help debugging. One is The ability to
easily setup unit tests on a component's methods. This is long overdue, and
since the layout is seperated from the code like it is, there's nothing
_visual_ about any of the code, and it's a pretty gross omission not to have
Iowa making it easy to unit test what those methods do.
The second is a better webside handling of exceptions. I'm stealing one of
DHH's tricks here and setting it up so that one can tell Iowa that for
certain requesting addresses, if an exception occurs, show it nicely
formatted in the browser so that it's easy to find the information that one
needs, and for all other requesting addresses display a
configurable "something has broken in a bad way; contact so-and-so" page to
the user. I'd love to use the PrettyExceptions class that was mentioned
recently, but I need to have code that runs on Win and *nix platforms and
that doesn't have an external dependencies, so I'm rolling my own (unless
someone knows of something that is already written that I could use).
The third is actually just a regular component to help with development.
One can stick it into one's standard footer, or just in specific pages, if
one wants, and while one is in development mode, it will display a simple
debugging toolbar at the bottom of the page that lets one take a peek into
the internals of the page and of the app. When one switches a component to
production, the component will switch itself off, but you can leave it in
the code so that if and when you come back and do more development or need
to debug something, you can just turn it on again.
All of the above will be in 0.9.2, so if you have any other suggestions on
things to make debugging easier, let me know!
Thanks,
Kirk Haines
(nursing a slightly sore knee and hand because I narrowly averted dropping a
1000 lb. trailer and the 350 lb. transmission in the back of it on my leg a
little bit ago, and then I tried crushing my hand between the trailer and a
100 lb. rock that I was putting on it as a counterweight; ow.)
