Stuff I done learned about Hobo

by Paul Agapow
in programming

tagged ruby, ruby-on-rails, web-development

Stuff I done learned about Hobo

In which I discover things, sometimes painfully.

Unless otherwise stated, done using Ruby 1.9.2, Hobo 1.0.3 (and hence Rails 2.3.10):

Permissions

It seems that permissions in Hobo can be a little tricky, in so much as I've had a case where something that behaved appropriately under a test environment, starting throwing permissions errors under development. In particular, the error “view of non-viewable field 'foo'” seemed to trigger problems where a link or foreign key field caused problems. Issues included:

Test for a guest then an admin then for user properties: otherwise the admin may fail on the user properties.

Write a permission method for the specific field: e.g.:

def poster_view_permitted?
   true
end

Check the permissions on the referred class

Scripts

You can call “server” with -p to set the port and -P to set the path, so you can test serving the site at a subdomain:

.script/server -p 9123 -P /saird

You can pass an environment via -e or set the env with a bash call. This is useful for testing the production version:

RAILS_ENV=production ./script/server -e production

Do the migration of the production database from your development environment in a similar way:

RAILS_ENV=production rake db:migrate

Generate with -p to “pretend” (don't actually make the changes):

./script/generate hobo_migration -p

Customizing templates

DRYML is sufficiently strange that if you want to customize the appearance, it can be hard to know where to start. Some tips:

1. Copy the appropriate template of another object, delete the object specific features and use

  1. Copy the auto-generated template from app/views/taglibs/auto/rapid
  2. Use the psuedo tags

Anomalies

Had a very strange error where I was using Less (via More) and “sudddenly” (when I chnaged the less stylesheet for the first time in weeks), the site errored out, complaining “uninitialized constant Less::Engine). The More maintainers have since moved on to the Next Big Thing (converting .less via javascript) but I had no desire to follow. The solution turned out to be reinstalling the more plugin:

% ./script/plugin remove more % script/plugin install git://github.com/cloudhead/more.git

and regenerating the stylesheets manually:

% rake more:generate

CookieStore::CookieOverflow

“Status: 500 Internal Server Error ActionController::Session::CookieStore::CookieOverflow”

Should you get this error, you're probably passing results or other data in the session, which by default is held in a cookie. You've overflowed the cookie data limit of 4K. Behaviour can be a bit subtle if you are using lazily evaluated records, as accessing a new fields can be enough to throw you over the limit. There are a few solution:

  1. Store the session another way, say in the database
  2. If you're returning records, instead return the record ids and fetch them when you need them

See: http://justbarebones.blogspot.com/2009/03/cookierstorecookieoverflow.html

"wrong number of arguments"

After creating a new model class and editing it, the subsequent migration failed with a cryptic error:wrong number of arguments (1 for 2). Calling the generator with traceback enabled, pointed out the new class as the error:

./script/generate hobo_migration -t

That's because the ”:required” keyword on a field was spelt ”:requires”:

fields do
   description :text, :requires
end

Changed and fixed. Easy.

Strict DRYML

The DRYML parser is far less forgiving than your typical web browser - it has to be legalXML. So while a browser will put up with this:

<input type="hidden" name="submitted" value="true">

Hobo insist that it be like this:

<input type="hidden" name="submitted" value="true" />

Permissions on subordinate objects

Discovered by Ali and recorded for when we encounter this again.

A strange situation arose in the creation of a Hobo model that had children that were another model that could be created inline, a classic one-to-many:

class Foo < ActiveRecord::Base
   hobo_model # Don't put anything above this
   [...]
   has_many :bars, :accessible => true, :dependent => :destroy

and:

class Bar < ActiveRecord::Base
hobo_model # Don't put anything above this
[...]
belongs_to :foo

The aim was to allow users to create a Foo, with a variable number of children Bars created inline on the same form. Users would be unable to later edit or delete these objects. Thus permissions were set allowing non-admin users to create Foos and Bars but other actions were denied.

A strange behaviour ensued: if an admin created a Foo, all fields appeared as expected, including the list of Bar children, with the javascript-enabled + and - buttons to add or delete children. If the user was non-admin, the children would not appear, although other relationships would.

After a great deal of trial and error, the problem was identified. Non-admin users require the destroy permission for the bar children to appear, even on a form for the de novo creation of Foo. Perhaps this is because the child delete (minus) button requires this permission. Perhaps it's because the new form and edit forms are one and the same. More investigation is required.