I started out intending to document *all* the ways one can encapsulate functionality in a Hobo app (engines, etc) but there are some nasty bugs with that mechanism. So, for now, just a quick primer on how to pull common functions out of your models.
The key to this approach is ActiveSupport::Concern (http://api.rubyonrails.org/classes/ActiveSupport/Concern.html) which cleans up some of the standard patterns around using modules. Here's a sample: # in a file, perhaps in lib or in a gem: module AddSomeFields extend ActiveSupport::Concern included do fields do name :string timestamps end end end The "included" block is where the real fun happens - it gets instance_evaled on the class the module is included into. Here's an example of using this module: class Project < ActiveRecord::Base include AddSomeFields end Running 'hobo g migration' with this in app/models/project.rb will create the projects table with the expected fields. You can also define instance methods in the module: module AddSomePermissions extend ActiveSupport::Concern def create_permitted? ... end end And then call them via 'super' in the model: class Project < ActiveRecord::Base include ExtensionStuff::AddSomeFields include ExtensionStuff::AddSomePermissions def create_permitted? # super checks the included modules before ActiveRecord::Base super && something_project_specific end end There's also some nice functionality in ActiveSupport::Concern for declaring that a module depends on another module; see the documentation for more details. You can do nearly anything in a module that you'd typically do in a model; one current limitation is that lifecycles can add additional states and transitions but not change existing transitions. --Matt Jones -- You received this message because you are subscribed to the Google Groups "Hobo Users" 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/hobousers?hl=en.
