I have figured out the problem. before_create_save is never called.
I wound up single stepping through way too much code. I wonder if
ruby-debug has some way to put a break point
at the location where an exception is raised?
The problem was in active_scaffold/lib/active_scaffold/
attribute_params.rb, in update_record_from_params.
The "attributes.each" was causing the nil exception. (should it
protect itself?), and this called from
create.db, do_create:
@record = update_record_from_params(new_model,
active_scaffold_config.create.columns, params[:record])
Suddenly, I asked, why is params[:record] nil? Then I asked... why
is the new object expected in params[:record],
rather than params[model.to_s] ?
I can see why AS might want to regularize how things are submitted,
but stock rails scaffold'ed controllers would
have used a params named after the model. I'm sure that this is
documented somewhere, but I certainly missed it.
I adjusted my test case to read:
post :create, :record => {
:email => '[email protected]',
:fullname => 'Frank Jones'
}
I also think that AS should return a 201 status code on create, even
if it renders a view in HTML.
On Jun 7, 8:48 pm, Michael Richardson <[email protected]> wrote:
> On Jun 6, 12:35 am, Hernan Astudillo <[email protected]> wrote:
>
>
>
> > looks like AS can't reach columns array.
> > Try to logger.info the record object with before_create_save(record)
> > in your controller to see if AS is getting it and parsing columns.
>
> Thanks, I'l try this.
>
> > > Too many layers to debug through, and obviously the error is not at
> > > line 13. Line 13 is just the post :create line.
> > > If I insert my own "def create" method (rather than let AS provide
> > > it), then I have no problems, but of course, then I have have to
> > > generate out everything including the views, etc. which isn't what I
> > > wanted to do...
>
> > > Even a clue on how to debug this would be great.
>
> > you can get ruby_debug gem. It let's you go through all the whole
> > process. It's long, but you can see everything AS do (plus all rails
> > stack). You can pause the process and examine objects, even execute
> > (tweak) code.
>
> I know well how to use ruby-debug. The problem is that there are
> multiple places
> where send() is used and sometimes eval, and each of those things
> makes the traceback stack difficult to follow,
> and there are simply too many places where you don't know whether to
> step vs next, and you either spend an
> hour tracing through code that didn't matter, or you miss the
> important part. Binary search would be useful
> if you could line up all the code linearly, but it's not written that
> way.
>
> I've considered some kind of meta-programming that would print the
> name of each function as
> it is entered/exited: I imagine it already exists, but I haven't
> figured out how to do that. It would be
> big and slow, but it would help for situations like this.
--
You received this message because you are subscribed to the Google Groups
"ActiveScaffold : Ruby on Rails plugin" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/activescaffold?hl=en.
