OgAdminController#save still broken

Ruby Apps Nitro
1

request[‘foovar’] works fine normally ( see illustration code ) but
blows up inside OgAdminController#save (again, just run the attached
sample code )

Run using a fresh darcs get. Am I the only one seeing these problems
with OgAdminController#save? Is nobody using the admin part? Is it
somehow related to using WEBrick or SQLite?

With each new darcs get I put my own workaround into OgAdminController
– replacing request[] with post_params[], after which everything works
fine.

ERROR: Error while handling OgAdminController#save()
ERROR: undefined method `[]’ for nil:NilClass

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/context/request.rb:304:in
`[]’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/nitro/lib/nitro/part/admin/og/controller.rb:93:in
save' (eval):4:incall’
(eval):4:in `save’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/compiler.rb:65:in
`send’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/compiler.rb:65:in
`save___super’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/controller/publishable.rb:36:in
`send’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/controller/publishable.rb:36:in
`method_missing’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/controller/render.rb:92:in
`send’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/controller/render.rb:92:in
`render_action’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/adapter.rb:68:in
`send’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/adapter.rb:68:in
`handle_context’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/adapter/webrick.rb:134:in
do_POST' /opt/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:insend’
/opt/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in
service' /opt/local/lib/ruby/1.8/webrick/httpserver.rb:104:inservice’
/opt/local/lib/ruby/1.8/webrick/httpserver.rb:65:in run' /opt/local/lib/ruby/1.8/webrick/server.rb:173:instart_thread’
/opt/local/lib/ruby/1.8/webrick/server.rb:162:in start' /opt/local/lib/ruby/1.8/webrick/server.rb:162:instart_thread’
/opt/local/lib/ruby/1.8/webrick/server.rb:95:in start' /opt/local/lib/ruby/1.8/webrick/server.rb:92:ineach’
/opt/local/lib/ruby/1.8/webrick/server.rb:92:in start' /opt/local/lib/ruby/1.8/webrick/server.rb:23:instart’
/opt/local/lib/ruby/1.8/webrick/server.rb:82:in `start’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/adapter/webrick.rb:57:in
`start’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/nitro/lib/nitro/application.rb:135:in
start' ./app.rb:34 LOGGED FROM: /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:108:inrender_action’

#!/usr/bin/env ruby

require ‘nitro_and_og’
include Nitro

require ‘nitro/part/admin’

class Book
attr_accessor :title, String
many_to_many Author
end

class Author
attr_accessor :name, String
has_many Book
end

Og.start( :adapter => :sqlite, :database => ‘library’,
:create_schema => true, :destroy_schema => true )

class MyController
def index
render_text “admin
Sample Form”
end

def sampleform
render_text "
"
end

def samplepost
render_text “You entered ‘#{request[‘foo’]}’ in the text field”
end

end

app = Application.new
disp=app.dispatcher
disp.root = MyController
app.start

2

I have this same issue in 0.50.0

3

I am using a custom Admin like part, so I have not seen it.
Rob, can you send me a patch for this?

-g.

4

Could I try the custom admin part? I’m wondering why that would behave
differently.

What’s attached is a workaround – calling request.post_params[‘oid’]
instead of request[‘oid’]. What should really be fixed – which will
take a while to get to – is whatever’s causing the request[‘oid’] to
fail in OgAdminController despite working elsewhere. Looks a bit like
an order of initialization thing, or a clash between two definitions.

I forget whether you need tar.gz or gz so here’s both.

5

Could I try the custom admin part? I’m wondering why that would behave
differently.

by custom I mean totally recoded :wink: When it is ready for public
consumption
I will release it
as an alternative to the AdminPart.

-g.

PS: thanks for the patch.