HoboCookbook - recipes

Mobile & iPad friendly sortable-collections

2012-08-21T03:53:44Z

I could not get [sortable-collection](http://cookbook-1.0.hobocentral.net/api\_tag\_defs/sortable-collection) drag-and-drop to function on mobile devices and iPads and had to come up with the following solution. For the purpose of this recipe, we are going to build on the [Task re-ordering](http://cookbook-1.0.hobocentral.net/tutorials/agility#task_reordering) in the Agility Tutorial (stories have many tasks that can be re-ordered). To app/controllers/tasks_controller.rb file, add the following: web_method :move_higher web_method :move_lower To the app/models/task.rb file, add the following: def move_higher_permitted? editable_by?(acting_user, :position) end def move_lower_permitted? editable_by?(acting_user, :position) end To the app/views/taglibs/application.dryml file, add the following:

Aside: please suggest a better tag name than "button-sortable-collection". To the public/stylesheets/application.css file, add the following: div.ordering-buttons { float: left; color: white; margin-left: -10px; padding: 0; } Change the app/views/stories/show.dryml file to: It would be nice if this functionality could be added to the Hobo core, but it requires a better understanding of Hobo that I have.

Use your own hobo fork

2012-06-23T10:27:19Z

If you want to use your own hobo-version and also help fixing problems, there are some easy steps to do this. **Fork hobo:** - you need a [github account] - fork [hobo] - see also [fork-a-repo] >If you have push problems: > > - git config -l # to see your config > - change git config line to use ssh: > remote.origin.url=ssh://git@github.com/YOUR_NAME/hobo.git **Add this line to your Gemfile:** gem "hobo", "=VERSION", :git => 'git://github.com/YOURNAME/hobo.git' -> e.g. gem "hobo", "=1.4.0.pre6", :git => 'git://github.com/kredmer/hobo.git' (and remove your old gem "hobo" line !) **run in console to update your gemfile.lock:** bundle update hobo **YOU ARE DONE !** Check issues and send a [pull-request], if you solved a problem. [github account]: https://github.com/ [hobo]: https://github.com/tablatom/hobo [fork-a-repo]: https://help.github.com/articles/fork-a-repo [pull-request]: https://help.github.com/articles/using-pull-requests

Appcelerator Titanium (Mobile App) and Hobo

2012-02-11T18:23:29Z

Hi all, I've tried searching for documentation on using Titanium (or anything) to make a mobile app (iOS/Android) from a Hobo app. I wanted to use Hobo both as a front-end and a back-end. While, I have seen this documented well outside of the Hobo world, I had not seen much on the combo of the two. (As always throughout, please correct me if I am wrong.) An example of a combo Rails/iPhone app is [here](https://github.com/clarkware/budgets-iphone) However, given I don't know Objective-C, and I like the Hobo-style...so I set out with [Appcelerator](http://www.appcelerator.com/). ----- The first issue was authentication. I knew I did not want to get deep into how Hobo authenticates, so I decided to use "Basic Authentication" - passing the username and login in the [HTTP header.](http://en.wikipedia.org/wiki/Basic_authentication) NOTE that this is wildly not secure unless you use HTTPS, which I am planning to use in production (unless someone comes up with a better idea). In general, I followed this really amazing [tutorial.](http://mobile.tutsplus.com/tutorials/appcelerator/titanium-user-authentication/) Also, [here](http://timneill.net/2011/06/simple-remote-requests-with-titanium-appcelerator/) is another guy that wrote a function to make all his data connections. I just made a new controller method that just returns some basic user information, in a controller that is protected by login (by adding the below to one of my controllers). before_filter :login_required This way Appcelerator etiher gets JSON information or redirected to the login page, which results in an error. From then on, in the header of the communication, I just pass what was given to be as a "Set-Cooke" back as a "Cookie." (Header fields are described [here](http://en.wikipedia.org/wiki/).) There are a few important nuances at this point: 1) Appcelerator errors out whenever you have an HTTP error on the Rails side (mostly manifests as "406 Not Acceptable." You must set the [Content-Type header.](http://developer.appcelerator.com/question/116980/iphone--rails--xhr--undefined-method-tosym-for-nilnilclass#203901) xhr.open('GET', url, false); xhr.setRequestHeader('Content-Type', 'application/json'); xhr.send(); 2) Pass authentication details [encoded in Base64](http://developer.appcelerator.com/question/120731/xhr-authentication-with-restful-api) 3) Store the cookie details in an [Appcelerator "property"](http://developer.appcelerator.com/question/117952/remember-me--session-implementation) 4) Appcelerator has what I think is a bug, and sometimes does not like the cookies that Hobo produces. When you pass the header back to Hobo, you have to use ["cookie"](http://developer.appcelerator.com/question/118509/can-i-set-cookie-whose-value-include-equal-on-http-request) instead of "Cookie" (otherwise it errors out). Creating methods in the controller (in Hobo) that send JSON is really easy. It is quite awesome actually. More on that [here.](http://stackoverflow.com/questions/2566759/how-can-i-generate-json-from-respond-to-method-in-rails) In general you can simply do something like this: show_action :new_show def new_show hobo_show do render :json => @this.to_json end end I mainly created new methods just so I didn't mess up the old ones, and so I did not have to deal with the respond_to and content-type issues. There are some create tutorials on what to do with the data in Appcelerator once you have it. [This one!](http://developer.appcelerator.com/blog/2011/08/handling-remote-data-with-httpclient-and-json.html) Also, one more thought on this - get the [KitchenSink app](https://github.com/appcelerator/KitchenSink)! You can copy and paste components practically. I am about to embark on writing the part that allows me to create data on the mobile side, and pass it back up. I'm not sure how this will pan out, but I think it will probably involve turning off [protect from forgery](http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html#method-i-protect\_from\_forgery) (that token on the web-side forms....or possibly, this might not be a problem with POST requests??) ----- Please punch holes in this - I want to hear what has worked for others, and what might be wrong with what I am doing. It also took me a while to find these resources, so I thought it would be important to share. Also given the text java-script field definitions, and the general simplicity, I could see writing generators to make Appcelerator components from Hobo models!! Anyone interested?? Cheers!

Quick-and-Dirty Required Field Highlighter

2011-09-20T15:50:31Z

After almost a year of beta testing, the REAL users requested that the required/mandatory fields be highlighted. (I had thought of this last year at the beginning of development, but could not figure out how to do it, then). I recently found a thread from January 2011 that discussed this capability\. In this thread, the use of <feckless-fieldset> was recommended. I tried this and got it to work (functionally, that is; it would highlight the required fields), but it took much too much time to style. Unless I missed something, each page needed to be styled independently which would have taken more time than I had available. After examining the <feckless-fieldset> code, it appeared that the highlighting capability could be merged with the normal <field-list> tag to give me the effect that I wanted. I modified <field-list> to produce <field-list-star-required> (star-required being the imperative, meaning put a star (\*) on each required field). Using this, I could change the form code from: to: I put the following code in application.dryml (I should have put it in a separate file, but as the title says, "quick and dirty"): no_edit} if tag == "input" -%> *

and the following code in application.css: .required { color : red; } The resulting form, when being edited, shows each of the required field's captions with a red asterisk appended. Just what I needed, no more, no less. If anyone would like to extend this such that the required fields in the model replace the static list in the tag's invocation, please do so (and let me know!).

Cut and paste (almost) recipe to add the tiny-mce editor to hobo apps.

2011-09-07T19:33:02Z

In my RoR days, I used the tiny-mce editor when ever I wanted to edit html fields. I searched the web for hobo versions of html editors and found Hoboyui in another recipe in this Cookbook. I followed the recipe and got an editor that worked, but all of the buttons were blank. Further investigation showed that the Yui folks were rationalizing their directory structure and even some of their own members were complaining about blank buttons. I could not find the button image data anywhere on their website or on the rest of the web for that matter. After hours of searching, I gave up. Remembering the success I had with tiny-mce in the past, I decided to hoboize it. If you don't already have it: [sudo] gem install tiny_mce edit your Gemfile, adding the line: gem 'tiny_mce' then: bundle install edit config/application.rb, adding the line: config.gem 'tiny_mce' edit taglibs/application.dryml, adding the lines: Add the file public/javascripts/hoboTinyMce.js (see comments about file name): // This file is hoboTinyMce.js // // I had extreme agony when the file was named "hobo_tiny_mce.js" // the editor would not initialize and the log showed many unresolved // javascript files. After renaming the file, everything just worked. // function tinymce_page_loaded() { var elements=document.getElementsByTagName("textarea"); for(i = 0;i < elements.length;i++) { className = elements[i].className // Only diddle with hobo :html fields, ignore :text, etc. if(className.indexOf('html') > -1 ) { elements[i].className = className + " mceEditor"; } } } Now modify the controllers of those pages that need the html editor. This is where you can customize the appearance of tiny-mce on a page-by-page basis. If you do not include a "uses\_tiny\_mce" line, the page will not invoke tiny-mce even if the model has an :html field. controller 1: uses_tiny_mce # shows a very simple editor (with controls on the bottom as the default). controller 2: uses_tiny_mce(:options => { :theme => 'advanced', :theme_advanced_toolbar_align => "left"} ) # fancier editor Note that the :options hash allows you to customize all of the pages associated with any particular controller. It is the equivalent of the javascript tiny_mce:init( .... ) except that it works on a controller-by-controller basis whereas the init works on every editor on the site. See http://tinymce.moxiecode.com/documentation.php for details about options and themes. There are so many configuration items that it would be inappropriate to show them all here. Besides the doc site does a much better job of explaining them than I can.

I18n Internationalization for beginners

2011-09-06T18:21:37Z

#Step 1: Create a new Hobo app (we are using Hobo 1.3 RC for this tutorial) > hobo new i18ntest (usual options in wizard, assuming you don't rename the user model name) When defining locales, add the needed ones: en es fr de > cd i18ntest #Step 2: Create a UserLocale class to store the available locales > hobo g resource UserLocale ... > edit app/models/user_locale.rb fields do +name :string, :required, :unique, :limit => 5+ timestamps end +has_many :users+ > edit app/models/user.rb +belongs_to :user_locale+ > hobo g migration ... > rails server #Step 3: Signup as administrator and add some user locales: en es de fr > edit app/controllers/user_locales_controller.rb -auto_actions :all- +auto_actions :all, :except => :index+ #Step 4: Edit your user and select the correct locale (note that the field list will show something like `" en". ` Is it probably a bug? #Step 5: Add some information in the page footer to help you understanding the process. > edit app/views/taglibs/application.dryml
User:
Locale:
Params Locale:
User Locale:
Default Locale: This will add the information about the locale variables. Our precedence will be: params > user > default. That is: if there exist a ?param=xx URL parameter, it will be the locale of the page to be shown. If not, then the page will take the current_user.user_locale as locale. If the current_user is not logged or has no locale set, then the default locale of the application will be used. #Step 6: Configure the I18n for the application > edit config/application.rb uncomment and tune: -# config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}').to_s]- -# config.i18n.default_locale = :de- +config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}').to_s]+ +config.i18n.default_locale = :en+ > edit apps/controllers/application_controller.rb before_filter :set_locale def set_locale if (params[:locale]) I18n.locale = params[:locale] else if (current_user.signed_up?) I18n.locale = current_user.user_locale.to_s else I18n.locale=I18n.default_locale end end end =begin def default_url_options(options={}) logger.debug "default_url_options is passed options: #{options.inspect}\n" { :locale => I18n.locale } end =end Please note that the =begin and =end code will only work fine in the production mode. The development fast user switcher will fail if you activate this, so we will not uncomment this until the problem is fixed. #Step 7: The application must be restarted in order to allow this configuration to take effect. #Step 8: Add the user_locale field to the signup page. > edit apps/models/users create :signup, :available_to => "Guest", -:params => [:name, :email_address, :password, :password_confirmation],- +:params => [:name, :email_address, :password, :password_confirmation, :user_locale],+ :become => :active def update_permitted? acting_user.administrator? || (acting_user == self && only_changed?(:email_address, :crypted_password, -:current_password, :password, :password_confirmation))- +:current_password, :password, :password_confirmation,:user_locale))+ end #Step 9: Test the locale preferences are working Create a new user and set a different locale for him (f.i. 'en' for admin and 'es' for the new user). Use the development fast user switcher to switch between the useres and see how this change the language the Hobo app is using. #Step 10: Activate the default\_url\_options to test the URL param method. > edit apps/controllers/application_controller.rb -=begin- +#=begin+ def default_url_options(options={}) logger.debug "default_url_options is passed options: #{options.inspect}\n" { :locale => I18n.locale } end -=end- +#=end+ #Step 11: Test the URL params work. Go to admin user, and go to home. Add ?locale=fr to the URL, and you see the changes. Try adding ?locale=de, and see how it changes. Please note: * If you use the "Login" "Signup" links, the locale is correctly keeped. * If you use the "Home" link, then the locale is missing. * If you try to change the user using the development fast switcher, it will fail. This is because it forces urls like instead of Try to use it, and change the ? to & to see it works. #Step 12: Let's fix these problems: Copy the apps/views/taglibs/auto/rapid/pages.dryml definition of main-nav to the apps/views/taglibs/application.dryml. In apps/views/taglibs/application.dryml file, add the '?locale=#{I18n.locale}' text to the href of the Home item: >edit apps/views/taglibs/application.dryml -Home- +Home+ #Step 13: Let's add some flag icons in the footer to change the param[:locale], to allow the Guest user to change the locale of the web. > edit app/views/taglibs/application.dryml 0)+" ES", "?locale=es" %> 0)+" EN", "?locale=en" %> 0)+" FR", "?locale=fr" %> 0)+" DE", "?locale=de" %>

> edit app/views/taglibs/application.dryml ++
User:
Locale:
Params Locale:
User Locale:
Default Locale: #Step 15: The system is almost complete. A user can specify the locale to use in the web session by clicking on the flag. If not specified, the locale will be his/her preference in his her profile. If not, the locale will be set from I18n.default_locale #TO DO: * Solve the problem with the development fast user switcher. * Populate automatically the UserLocale class with the locales found in the config/locales directory, or find a solution that does not require a model. * When a user has a locale1 preference and uses the flag to select the locale2 preference, some links will ignore the default\_url\_options functions: the users->show action and the users->account action. * In the user->show action, solve the way the User Locale is shown (User locale `en)`

Upload Progress Bar with Hobo and Paperclip

2011-06-12T05:39:03Z

This recipe has been tested with Hobo 1.0.1 and Rails 2.3.8. It uses Phusion Passenger, Ajax and a iframe hack to get a nice ajax progress bar for the uploads. Before we start, you can take a look at [the demo video I recorded](http://ihuerta.net/lang/en-us/2011/06/new-hobo-recipe-using-a-progress-bar-with-hobo/) and the [complete demo in .tar.gz](http://ihuerta.net/wp-content/uploads/2011/06/demo\_progress\_bar.tar.gz). Step One: Create two tables and install paperclip ================================================= We create the application and two tables: clients and attachments

hobo demo\_progress\_bar
cd demo\_progress\_bar
script/generate hobo\_model\_resource client name:string
script/generate hobo\_model\_resource attachment

Every *client* has_many *attachments*:


# app/models/client.rb
has_many :attachments


# app/models/attachment.rb
belongs_to :client

Create and run the migrations:

script/generate hobo_migration

Now we add the Hobo magic to connect the clients and the attachments:


# app/viewhints/client_hints.rb:
children :attachments


# app/controllers/attachments_controller.rb:
  auto_actions :write_only
  auto\_actions\_for :client, :create
end

Next we install Paperclip and Paperclip with Hobo.

script/plugin install git://github.com/thoughtbot/paperclip.git
script/plugin install git://github.com/tablatom/paperclip\_with\_hobo.git

I found a bug between the latest paperclip and paperclip\_with\_hobo, so you can try this slightly older paperclip revision (untar it in vendor/plugins): http://ihuerta.net/wp-content/uploads/2011/06/Paperclip.tar.gz

cd vendor/plugins
wget http://ihuerta.net/wp-content/uploads/2011/06/Paperclip.tar.gz
tar xzfv Paperclip.tar.gz

Now we prepare the model, the views and the migrations


      has_attached_file :file, 
          :whiny => false, 
          :path => "#{RAILS_ROOT}/files/:id.:extension"
      validates_attachment_size :file, :less_than => 5.megabytes
      validates_attachment_presence :file


      def name
        file.original_filename
      end
      
      def size
        if (file_file_size / 1024) < 1024
          (file_file_size / 1024).to_s + ' KB'
        else
          (file_file_size / 1048576).to_s + ' MB'
        end
      end

app/views/clients/show.dryml app/views/taglibs/application.dryml

Size:

Date:

app/controllers/attachments_controller.rb def download attachment = Attachment.find(params[:id]) send_file 'files/' + attachment.name end

script/generate hobo_migration

Step 2: Start tracking the uploads with Phusion Passenger ========================================================= In order to track the progress of uploads, we need the server to give us that information. "Apache Upload Progress Module" is a nice extension that solves our problem. Download https://github.com/drogus/apache-upload-progress-module Extract it Install it

sudo apxs2 -c -i -a mod\_upload\_progress.c

Prepare the virtualhost to track uploads: ServerName demo_progress_bar.localhost DocumentRoot '/home/ignacio/Trabajos/2_Proyectillos/Hobo/demo_progress_bar/public' RailsEnv development AllowOverride all Options -MultiViews # enable tracking uploads in / TrackUploads On # enable upload progress reports in /progress ReportUploads On And a nice tip if you are working with Ubuntu. While you are testing in localhost, it's very nice to simulate a slow upload speed so you can actually see the bar moving. I use this iprelay command and work through http://demo\_progress\_bar.localhost:8002

iprelay -b350000 8002:demo\_progress\_bar.localhost:80

Before we start with the upload bar, let's check if the tracking is working. First we add a test UUID to the file upload request: app/views/clients/show.dryml: Testing the upload URL When you reload the client page, you will see a link that gives you a JSON answer, something like:

{ "state" : "starting", "uuid" : "659102713689307356231103628731" }

This means the download hasn't yet started. If you are uploading the file, the JSON should be:

{ "state" : "uploading", "received" : 47104, "size" : 173966, "speed" : 47104, 
"started_at": 1307856054, "uuid" : "659102713689307356231103628731" }

With this info we are going to create the progress bar :) Step 3: Build the progress bar ============================== Now let's get to the fun part. First we need a JS function to take care of the progress-bar. Basically it gets the JSON info every couple of seconds, and based on the answer it decided what to do: public/stylesheets/application.js: function hoboprogress(uuid){ // Make the progress bar appear $('progress-bar').setStyle('display: block;'); // Reload the Progress Bar every 2 seconds new PeriodicalExecuter( function(pe){ new Ajax.Request("/progress",{ method: 'get', parameters: 'X-Progress-ID='+uuid, onSuccess: function(xhr){ /* When we get the upload info in JSON, we evaluate it */ var upload = xhr.responseText.evalJSON(); if(upload.state == 'uploading'){ /* Calculate the percentage */ upload.percent = Math.floor((upload.received / upload.size) * 100); $('progress-bar').setStyle({width: upload.percent + "%"}); $('progress-bar').update(upload.percent + "%" + upload.speed); }; /* Once we are in the 100%, we trigger some stuff */ if(upload.state == 'done' || upload.percent == 100){ // Stop the PeriodicalExecuter pe.stop(); // Change the message $('progress-bar').update('Saving...'); // Update the file list (we wait a second so the server writes the new file to the DB) Hobo.ajaxRequest.delay(0.8,'/clients/show/3', ['collection'],{ onSuccess: function(response){ // Hide the progress bar once the update is complete $('progress-bar').fade(); }, message:false }); // Empty the file input box // This is a bit complicated to do cross browser // Apparently, replacing the HTML works best $('file-input').update(""); }; } }) },2 ); }; Ok, too much JS, I know. But the result is worth it! Now let's add the progress-bar div to the show.dryml, plus an iframe for the upload to work: app/views/clients/show.dryml   Last step: make the controller answer to Ajax requests:


# app/controllers/clients_controller.rb
  def show
    hobo_show do
      hobo_ajax_response if request.xhr?
    end
  end

Permissions through a nested has_many relationship.

2011-05-11T02:27:01Z

I have a app where the ability to assign many different users to review a project is needed. Each project should only be viewable by either the administrator or the assigned reviewers. What I did was discover a handy gem named "nested\_has\_many\_through" which allowed the hobo permissions access to the nested data. See [https://github.com/romanvbabenko/nested\_has\_many\_through] ("https://github.com/romanvbabenko/nested\_has\_many\_through") for more information about the gem in the recipe. Be sure to add the gem. Put this line in your Gemfile: gem "nested_has_many_through" and run: bundle install The models: Generate the project model: $ hobo g resource project.rb name:string app/models/project.rb class Project < ActiveRecord::Base hobo_model # Don't put anything above this fields do name :string description :text timestamps end has_many :reviews has_many :users, :through => :reviews # --- Permissions --- # def create_permitted? acting_user.administrator? end def update_permitted? acting_user.administrator? || acting_user.in?(users) end def destroy_permitted? acting_user.administrator? end def view_permitted?(field) acting_user.administrator? || acting_user.in?(users) end Now generate your review model: $ hobo g resource review.rb name:string app/models/review.rb class Review < ActiveRecord::Base hobo_model # Don't put anything above this fields do name :string timestamps end belongs_to :project has_many :review_assignments, :dependent => :destroy has_many :users, :through => :review_assignments, :accessible => true # Get a nice view of the relationships children :review_assignments children :users # --- Permissions --- # Then create your review assignment model: $ hobo g model review_assignment app/models/review_assignment.rb class ReviewAssignment < ActiveRecord::Base hobo_model # Don't put anything above this fields do timestamps end has_many :users has_many :reviews # --- Permissions --- # This is very handy if you want only admins to have the ability to create reviews and assign users. All that is needed is to move the reviews controller to the admin directory *(app/controllers/admin/)* and replace the first line of the file with this: class Admin::ReviewsController < Admin::AdminSiteController or when creating your model run the following command (*I have not tried this so YMMV*) hobo g resource admin::reviews name:string Now we're all set, run the following from the command line. $ hobo g migration $ rails s Add some users and programs then go to reviews and assign users to their programs. This application has been posted on Github, so feel free to check it out. [https://github.com/jdowning/Has-Many-Reviewers] ("https://github.com/jdowning/Has-Many-Reviewers")

Dynamic, Role-based Main Menu

2011-04-19T16:23:29Z

I have a demo site for this recipe that I posted to github. Keep in mind that I have never used github before and am a relative new-comer to git itself. https://github.com/dziesig/Hobo-Dynamic--Role-based-Main-Menu This recipe implements a Dynamic Main Menu whose contents are a function of the site's models and the User's Role(s), with each User potentially having both Primary and Secondary Roles. <bs> Background: My daughter is a successful Real Estate Broker here in Florida. <brag>She has degrees in Russian, French, Marketing and Computer Science.</brag> Together we collaborated on a Back Office Intranet originally implemented in Ruby-on-Rails (1.2 if I recall correctly). The menu system on that website was hard-coded to allow any given user to choose between two potential modes. For example, the Broker is also an Agent with different needs for each role. We had multiple roles: * Administrator (me) * Broker (my daughter) * Reviewer (new for the Hobo version) * Agent (my daughter plus many others) * InactiveAgent (few) * Unassigned (needed as a place holder). The design called for a main menu with the following tabs: * Home * ModeSelect (caption is based on user's alternate role) * Yada 1 (Required place-holder, never visible) * Yada 2 (Broker-specific) * * Yada 10 (Agent-specific) * * Yada 20 (Reviewer-specific) * * Yada 32 (it's a big site with many functions/data). After a really helpful tip from kevinpfromnm, which eliminated a lot of redundant editing between migrations, and which serendipitously improved the appearance of menus whose owners had primary and secondary roles, the menu design became: * ModeSelect (caption is based on user's alternate role, if any) * * * Home * Yada 1 (Required place-holder, never visible) * Yada 2 (Broker-specific) * * Yada 10 (Agent-specific) * * Yada 20 (Reviewer-specific) * * Yada 32 (it's a big site with many functions/data). The admin menu was: * Home * Permissions * Roles * Users The formats of these menus can be seen in the attached images (once someone tells me where the link is [hint, it is not the words "Upload image" on the left aside]). In the meanwhile, the images are in the github repository noted above under the doc directory. If all of the tabs on the main menu were visible simultaneously, there would be no room "above the fold" for application data. Also, there are things that the Broker/Administrator can do that we didn't want Agents know was possible. My original Hobo design (or lack thereof) used a hard-coded main menu that (like its Rails predecessor) was getting very hard to maintain. I took a step back (figuratively) and looked at what Hobo supplied in a "plain-vanilla" site with the intent of using dryml to extend it and map the main menu to the permission/role system. </bs> The setup wizard choices need invite-only/email-invitation so the admin can set user's roles in this recipe. There may be other ways for the administrator to setup the restricted attributes of users (specifically the user's role that only admin can change) but I haven't tried to find them. hobo new DynamicMainMenu cd DynamicMainMenu I found this permission/role implementation somewhere but I can't remember where. With a few mods to the original it works fine here. hobo g model permission_role hobo g resource admin::permission name:string description:string hobo g resource admin::role name:string description:string This will populate the menu with some items. hobo g resource test_with_space name:string hobo g resource yada1 name:string hobo g resource yada2 name:string hobo g resource yada3 name:string hobo g resource yada4 name:string hobo g resource yada5 name:string hobo g resource yada6 name:string hobo g resource yada7 name:string hobo g resource yada8 name:string hobo g resource yada9 name:string hobo g resource yada10 name:string hobo g resource yada11 name:string hobo g resource yada12 name:string hobo g resource yada13 name:string hobo g resource yada14 name:string hobo g resource yada15 name:string hobo g resource yada16 name:string hobo g resource yada17 name:string hobo g resource yada18 name:string hobo g resource yada19 name:string hobo g resource yada20 name:string hobo g migration At this point, you can start the app and see what happens when you have a lot of menu items. Note that the White *Current* tab impacts those below it. Edit application.css /* Fixes the over-sized current tab */ .page-header .navigation.main-nav li.current a { color: #222; background: url(../images/30-DBE1E5-FCFEF5.png) repeat-x #FCFEF5; border:0; } /* reduces size of the development-mode dryml file names */ /* Note, this comes from a mod I made to the hobo templates */ /* It is not necessary without my mods, but is present in the demo */ .dryml_file { font-size: 9px; } Refresh the page and the White current tab height returns to the default of the other tabs and the menu behaves normally. edit role.rb fields do name :string, :unique, :index description :string timestamps end has_many :users; has_many :permissions, :through => :permission_roles, :accessible => true has_many :permission_roles, :dependent => :destroy # --- Permissions --- # edit permission.rb fields do name :string, :unique, :index description :string timestamps end has_many :roles, :through => :permission_roles, :accessible => true has_many :permission_roles, :dependent => :destroy # --- Permissions --- # edit permission\_role.rb fields do timestamps end belongs_to :role belongs_to :permission def name if !role.nil? && !permission.nil? role.name + ' ' + permission.name else '' # just in case end end # --- Permissions --- # hobo g migration edit user.rb fields do name :string, :required, :unique email_address :email_address, :login => true, :required => true, :unique => true administrator :boolean, :default => false use_secondary_role :boolean, :default => false #when true, user assumes secondary role timestamps end belongs_to :primary_role, :class_name => "Role" belongs_to :secondary_role, :class_name => "Role" delegate :permissions, :to => :role def role if self.use_secondary_role? self.secondary_role else self.primary_role end end def alternate_role if self.use_secondary_role? self.primary_role else self.secondary_role end end def toggle_mode self.use_secondary_role = !self.use_secondary_role self.save! end # This gives admin rights and an :active state to the first sign-up. < ..... snip ..... > alias_method_chain :new_password_required?, :invite_only # set default roles to Unassigned before_save do |user| self.primary_role_id = 6 if self.primary_role.nil? self.secondary_role_id = 6 if self.secondary_role.nil? end # --- Signup lifecycle --- # < ..... snip ..... > #-------------------------------------------------------------------- # Roles, Permissions, has_multiple_roles #-------------------------------------------------------------------- def method_missing(method_id, *args) if match = matches_dynamic_role_check?(method_id) tokenize_roles(match.captures.first).each do |check| if self.role.name.downcase == check return true end end return false elsif match = matches_dynamic_perm_check?(method_id) if !permissions.nil? result = permissions.find_by_name(match.captures.first) return result end else super end end def has_multiple_roles? if self.secondary_role != nil return self.secondary_role != self.primary_role unless self.secondary_role.name == 'Unassigned' end false end private def matches_dynamic_role_check?(method_id) /^is_an?_([a-zA-Z]\w*)\?$/.match(method_id.to_s) end def tokenize_roles(string_to_split) string_to_split.split(/_or_/) end def matches_dynamic_perm_check?(method_id) result = /^can([a-zA-Z]\w*)\?$/.match(method_id.to_s) result end end hobo g migration edit users\_controller.rb < ..... snip ..... > def toggle current_user.toggle_mode redirect_to "#{base_url}/" end end edit routes.rb match 'search' => 'front#search', :as => 'site_search' match 'user/toggle' => 'users#toggle' # The priority is based upon order of creation: < ..... snip ..... > # Sample resource route within a namespace: # namespace :admin do # # Directs /admin/products/* to Admin::ProductsController # # (app/controllers/admin/products_controller.rb) # resources :products # end namespace :admin do resources :roles resources :permissions end Now for some DRYML magic (there may be a DRYer way for some of this, but it works for me). Create the file: app/views/taglibs/nav\_item.dryml  /, '').strip show_it = !(current_user.class == Guest) if show_it show_it = (name == 'Home') || (name == 'Permissions') || (name == 'Roles') || (name == 'Users') || (name.include?(' Mode')) if !show_it access = "current_user.canAccess" + this.to_s + "?" show_it = !(eval access).nil? end end -%> The following is only necessary if you absolutely need to re-arrange the menu. kevinpfromnm's tip populates the menu automatically by <extending...> the <main-nav> tag. Create the file app/views/taglibs/main\_navigation.dryml Copy the head of app/views/tablibs/auto/rapid/pages.dryml that contains the main menu into it, then make the noted change:  Home  Notice that I re-arranged the Yada's so they were in numeric order, not alphanumeric order. I did this only to be sure that we were NOT using the rapid-generated menu. Using the extended <main-nav> tag will return them to the original alphanumeric order. Edit application.dryml <!-- only if you used the <set-theme name="clean"/> End of the "don't do this unless..." section kevinpfromnm's tip. Create the file app/views/taglib/front\_site.dryml: <include src="rapid" plugin="hobo"/> <include src="taglibs/auto/rapid/cards"/> <include src="taglibs/auto/rapid/pages"/> <include src="taglibs/auto/rapid/forms"/> <set-theme name="clean"/> <extend tag="main-nav"> <navigation class="main-nav" merge-attrs param="default"> <mode-nav-item/> <old-main-nav merge-attrs/> </navigation> </extend> At this time, if you restart the app and refresh your browser, you will see a very empty main menu Now to populate the roles and permissions. Login as the administrator (first user). In the gitHub demo site, the admin email is a@a.com with 'Password' as the password (all users of the demo site have 'Password' as their passwords). Select the Admin link to get to the Admin sub-site. Select the Roles tab on the menu and start adding Roles. In the demo site they are (in descending capability order): * Administrator * Broker * Reviewer * Agent * InactiveAgent * Unassigned << note this is hard-coded in user.rb as the 6th item. You do not have to add permissions at this time. You do not have to order the entries except, for now, the 6th entry is the initialization value when users are created (I'll fix that soon, I hope). Select the Permissions tab on the menu and start adding menu permissions. Note that menu permissions start with Access and contain the SINGULAR name of the associated model. Thus in the demo site, * AccessYada1 * . * . * . * AccessYada20 map to each of the dummy model menu tabs, even though the tabs are captioned Yada1s, ..., Yada20s. In my real-estate app, I use the locales to re-caption the menu tabs (this works even if you only use a single language, I implement en and es so it is not much of an additional hardship) just because the model names don't necessarily map to concise labels. Let's add some permissions to the roles. Select the Roles tab on the menu and map permissions to each role as you like. I entered some pseudo-random associations in the demo site. Now add some users with various roles. Since I have not setup the email for the demo site, you will have to look in the terminal output for the email message and manually copy the link for the invitation acceptance, as in: Sent mail to betty@broker.org (711ms) Date: Sun, 17 Apr 2011 21:18:20 -0400 From: no-reply@0.0.0.0 To: betty@broker.org Message-ID: <4dab915cceea9_546d25615c84186cc@development.mail> Subject: Invitation to Dynamic Main Menu Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Betty Broker, You have been invited to join Dynamic Main Menu. If you wish to accept, please click on the following link http://0.0.0.0:3001/users/6-betty-broker/accept_invitation?key=48607c3d25d861ca00cb5062ae6662a3afcd58bd Thank you, The Dynamic Main Menu team. As soon as you issue the invitation (in the real world), edit the new user and assign appropriate roles. If you don't, and the new user is fast enough, she will encounter the situation where her roles are unassigned and she can't do anything. Play with the demo site and you can see how the dynamics work. The Broker and Reviewer both have alternate roles as Agents so the tab immediately to the left of Home allows them to toggle to the mode displayed on the tab. Note also that the permission system is not limited to the AccessMenuItem function. In my real-estate app, I have fine-grained permissions that enable/limit each role's ability to (for example) view or modify other user's data. The broker, in broker mode, can edit everyone's profiles; in agent mode, she can only edit her own profile. The permissions, in this case are: EditAllProfiles -- associated code: current\_user.canEditAllProfiles? EditOwnProfile -- associated code: current\_user.canEditOwnProfile? in the absence of either of these permissions, the user can not even edit her own profile. Many thanks to kevinpfromnm for tip on extending the main-nav tag. One last comment. If I were starting over, I would change the name of the Administrator role to something different to avoid confusion with the hobo user's administrator boolean. For me this is more of a political issue; the name could be easily changed by editing the Role, but the rest of the staff is accustomed to it, (backwards compatibility with the rails app where it did not conflict), so I'm stuck with it (unless I just do it).

A Simple Way to Do Location-Based Breadcrumbs

2011-03-20T22:49:40Z

For ease of navigation, our team decided to incorporate breadcrumbs into our Hobo site. In this method below, the breadcrumbs are based not on history, but on the current location of the user, the url. Since historical navigation can easily get quite deep and complex, it seems the wiser choice to maintain our adherence to the KISS (keep-it-simple-stupid) principle. If you're curious as to a discussion of the pros/cons of historical versus hierarchical breadcrumbs, i rather enjoyed this: http://derivadow.com/2010/02/18/the-problem-with-breadcrumb-trails/. Basically, I placed the following get\_bread\_crumb() function in my application's FrontHelper: def get_bread_crumb(url, root_model=nil, separator = " » ") root_model = root_model.pluralize breadcrumb = [] so_far = [] elements = url.split('/') last_element = elements.last # remove the last element, let dryml specify if last_element == 'edit' elements.pop(2) else elements.pop end elements.each_with_index do |element, index| so_far << element url = so_far.join('/') breadcrumb << if element =~ /^[0-9]*$/ link_to_if(element != last_element, elements[i-1].constantize.find(element).name.humanize, url) rescue element else link_to_if(element != last_element, element.titleize, url) end end # prepend the root_model IF we're not already in it! if root_model != elements[1] breadcrumb.insert(1,link_to(root_model.titleize, '/' + root_model)) end # return the breadcrumb breadcrumb.join(separator) + separator rescue 'Not available' end Then, simply place in application.dryml:  New

I chose NOT to include the name of the current page in the function for flexibility, leveraging Hobo's nice rendering of the name based on the context. For instance, on our Eteachables index page, we have the following DRYML:
which nicely generates the count of Eteachables in the breadcrumb: » Eteachables » 3 Eteachables We also chose to have a root model, in this case Eteachables, so the user can always quickly return to this primary location. For instance, one might navigate to the Math learning category, and while the url simply states /learning_categories/1-math the breadcrumb shows Eteachable as the root: » Eteachables » Learning Categories » Math In sum, the breadcrumbs, being just below the tabs, are a quick way to navigate while keeping it all very Hobo-feeling! Now if anyone can help me get the Edit button back on the Show page, I think that's the primary deficiency I've noticed at this juncture. I'll update the recipe with that edit once resolved. In the meantime, enjoy! *Special thanks for the considerable head start via https://gist.github.com/446655.*

Dropdown tab menus

2011-02-22T16:04:37Z

One of my clients insisted on having drop-down menus on her website. Since "The Client is Always Right" (tm), I had to find a quick way of doing this. 1) put main-nav in its own file. I used app/views/taglibs/main-nav.dryml. Once you do this, the automatic updating of menus stops, any future changes to the displayed menu must be done manually to this file. 2) add the following code to main-nav.dryml

/*********************************************** * Drop Down Tabs Menu- (c) Dynamic Drive DHTML code library (www.dynamicdrive.com) * This notice MUST stay intact for legal use * Visit Dynamic Drive at http://www.dynamicdrive.com/ for full source code ***********************************************/   3) Insert the following code in application.js (This should go in its own file, but I couldn't get it to work that way, at least in any reasonable time). //Drop Down Tabs Menu- Author: Dynamic Drive (http://www.dynamicdrive.com) //Created: May 16th, 07' /*********************************************** * Drop Down Tabs Menu- (c) Dynamic Drive DHTML code library (www.dynamicdrive.com) * This notice MUST stay intact for legal use * Visit Dynamic Drive at http://www.dynamicdrive.com/ for full source code ***********************************************/ var tabdropdown={ disappeardelay: 200, //set delay in miliseconds before menu disappears onmouseout disablemenuclick: false, //when user clicks on a menu item with a drop down menu, disable menu item's link? enableiframeshim: 1, //1 or 0, for true or false //No need to edit beyond here//////////////////////// dropmenuobj: null, ie: document.all, firefox: document.getElementById&&!document.all, previousmenuitem:null, currentpageurl: window.location.href.replace("http://"+window.location.hostname, "").replace(/^\//, ""), //get current page url (minus hostname, ie: http://www.dynamicdrive.com/) getposOffset:function(what, offsettype){ var totaloffset=(offsettype=="left")? what.offsetLeft : what.offsetTop; var parentEl=what.offsetParent; while (parentEl!=null){ totaloffset=(offsettype=="left")? totaloffset+parentEl.offsetLeft : totaloffset+parentEl.offsetTop; parentEl=parentEl.offsetParent; } return totaloffset; }, showhide:function(obj, e, obj2){ //obj refers to drop down menu, obj2 refers to tab menu item mouse is currently over if (this.ie || this.firefox) this.dropmenuobj.style.left=this.dropmenuobj.style.top="-500px" if (e.type=="click" && obj.visibility==hidden || e.type=="mouseover"){ if (obj2.parentNode.className.indexOf("default")==-1) //if tab isn't a default selected one obj2.parentNode.className="selected" obj.visibility="visible" } else if (e.type=="click") obj.visibility="hidden" }, iecompattest:function(){ return (document.compatMode && document.compatMode!="BackCompat")? document.documentElement : document.body }, clearbrowseredge:function(obj, whichedge){ var edgeoffset=0 if (whichedge=="rightedge"){ var windowedge=this.ie && !window.opera? this.standardbody.scrollLeft+this.standardbody.clientWidth-15 : window.pageXOffset+window.innerWidth-15 this.dropmenuobj.contentmeasure=this.dropmenuobj.offsetWidth if (windowedge-this.dropmenuobj.x < this.dropmenuobj.contentmeasure) //move menu to the left? edgeoffset=this.dropmenuobj.contentmeasure-obj.offsetWidth } else{ var topedge=this.ie && !window.opera? this.standardbody.scrollTop : window.pageYOffset var windowedge=this.ie && !window.opera? this.standardbody.scrollTop+this.standardbody.clientHeight-15 : window.pageYOffset+window.innerHeight-18 this.dropmenuobj.contentmeasure=this.dropmenuobj.offsetHeight if (windowedge-this.dropmenuobj.y < this.dropmenuobj.contentmeasure){ //move up? edgeoffset=this.dropmenuobj.contentmeasure+obj.offsetHeight if ((this.dropmenuobj.y-topedge)div a:hover /*THEME CHANGE HERE*/ { color: #242E42; background-color: #ffffff; } I fiddled with the css until the drop down looked like the main tabs. You will probably want to adjust the width to suit your drop down menu width, but it seems to adjust itself appropriately for most cases.

Save Context for table and table-plus

2011-01-24T12:59:59Z

One of my clients has tables with thousands of rows which are related positionally (adjacency is relevant) and have searchable values. Once a row is found it is often used in many subsequent operations. Consequently using the page navigator for rows in the middle of the current sort order is cumbersome. It was requested that I save the context between visits to the index pages to avoid the "page chase" that occurred when the user needed to return to the most recent row (or adjacent rows). Inspired by Dean's saving of filter_parameters in the session, but needing a more general solution, I put together a pair of subprograms to save and restore the context from within the controllers of the various tables. New file lib/table\_plus\_support.rb module TablePlusSupport def self.save_page(params, per_page, session, ignore=nil) field_list = '' # If we have a field to ignore (usually one with much data), # get a list of all columns excluding that one. # TODO Generalize this to allow ignore to be both a string and an array if !ignore.nil? index_fields = column_names.select{ |col| col != ignore } for i in index_fields do field_list = field_list + i + ', ' end field_list = field_list[0..-3] end # Default to the first page. page = 1 # Generate a session key from the name of the table. controller = params[:controller] key = controller+'-page' if params[:page] # If we have a page parameter, save it in the session page = params[:page].to_i session[key] = page else # If we don't have a page parameter get the page from the session if it exists page = session[key] if session[key] end # Return a series of tAssoc to satisfy hobo_index, here I presume that # pagination is desired since this wouldn't be called without it. return :per_page => per_page, :page => page, :paginate=> true if ignore.nil? return :per_page => per_page, :page => page, :paginate=> true, :select => field_list end def self.save_param(params,param,session) controller = params[:controller] key = controller + '-' + param.to_s sort = nil if params[param] # If we have a value in params[param], save it in the session value = params[param] session[key] = value else # The following line is weird. I tried using session[key].class == 'String', # but it always evaluated FALSE no matter what version of 'String', "String", :String # I used, even though session[key].class and session[key].class.inspect both printed "String" # Weirder still, session[key].class == session[key].class.inspect also evaluated FALSE # This version works, so ... # If we don't have a value in params[param], but we do have a string in session[key] # then use the value in the key value = session[key] if session[key].class.inspect == 'String' end # set params[param] if we have a value for sort. params[param] = value if value end end This does not mess up the controller too badly. An example, based on a smaller table which saves U.S. States and Canadian Provinces is: require "table_plus_support" class StateProvsController < ApplicationController hobo_model_controller auto_actions :all def index TablePlusSupport::save_param(params,:sort,session) TablePlusSupport::save_param(params,:search,session) hobo_index StateProv.apply_scopes(:search => [params[:search],:full_name,:name],:order_by => parse_sort_param(:name, :full_name)), TablePlusSupport::save_page(params,10,session) end end One somewhat obvious note: The search parameter will be saved until it is reset by issuing "Go" with a blank search box. Fortunately, the search box is re-populated so it is obvious that the filter is still in place.

Ajax file uploads

2011-01-16T16:44:27Z

Note: actually there's one or two steps missing here: you also need the formSubmit function in hobo-jquery. If you have questions, ping me on the list. Even better, this is built into Hobo 1.4. With the [paperclip plugin](http://cookbook.hobocentral.net/plugins/paperclip\_with\_hobo) installed, Hobo supports file uploads, but does not support Ajax file uploads. It seems like it should work, but the file doesn't get uploaded. The problem is that browsers do not allow Javascript access to the local file system as a security measure. To get around this, most sites either use a Flash plugin or use an ugly IFrame hack. We'll use the [JQuery form plugin](http://malsup.com/jquery/form/), which packages up the IFrame hack. You'll also need [this enhancement to Hobo](https://hobo.lighthouseapp.com/projects/8324-hobo/tickets/861-need-to-wrap-ajax-response-in-textarea). You can either install the patch, or use 1.1.0.pre3 or 1.3.0.pre26 (?). The first step is to install [JQuery form plugin](http://malsup.com/jquery/form/), using something like this: This assumes you're using the [hobo-jquery plugin](http://cookbook.hobocentral.net/plugins/hobo-jquery). See [its instructions](http://cookbook.hobocentral.net/plugins/hobo-jquery) for more details. On our application, we have a package that has-many uploads. class Package < ActiveRecord::Base hobo_model has_many :uploads, :dependent => :destroy end class Upload < ActiveRecord::Base hobo_model fields do name :string timestamps end has_attached_file :attachment belongs_to :owner, :class_name => "User", :creator => true end Our view is pretty standard Hobo Ajax:

Attachments

Add an Attachment

But we need some extra stuff in the controller to correspond to the requirements listed [here for the jQuery form plugin](http://malsup.com/jquery/form/#file-upload). class UploadsController < ApplicationController hobo_model_controller auto_actions :all, :except => [:index] auto_actions_for :package, [:create, :new] def create_for_package hobo_create_for :package do if valid? # we have to ignore the requested file type because the workarounds # necessary to send files via ajax don't allow us to set the # headers. So we just assume that we need to send an Ajax # response. We'll also Wrap that response in a textarea so # the browser keeps its hands off of it. ajax_update_response(params[:page_path], params[:render].values, {}, {:preamble => ""}) else render(:status => 500, :js => "alert(\"#{this.errors.full_messages.join(". ").gsub('\n', '')}\");") end end end end

Single Table Inheritance with Children

2011-01-14T22:50:50Z

I have used the design pattern which consists of STI with child tables in many situations before (RoR, Delphi, ... ). I looked for existing recipes but the existing one didn't exactly fit the design pattern (and didn't seem to work with Hobo 1.3 either). My current instantiation of the design pattern is as follows: The primary class is a Profile - it has children in the form of a list of Phone Numbers (and other lists, all of which are implemented the same way) - it is not directly manipulated (it could be, but I haven't tried. YMMV). There are three sub-classes of Profile: Agents, Clients, CooperatingAgents - (yes my client is a real-estate agency). Supporting tables: PhoneKind (e.g., Home, Office, Home FAX, Cell, ... ). I have simplified the contents of the various tables below by eliminating a lot of the real-estate-specific columns (which don't add to understanding the hobo problem/solution anyway) and permissions (which are also application-specific). The following assumes an hobo app named sti-with-children hobo new sti-with-children cd sti-with-children hobo generate resource phone_kind kind:string hobo generate resource phone_number number:string hobo generate resource profile name:string street:string #snip... hobo generate resource client hobo generate resource agent hobo generate resource cooperating_agent Edit the models: **phone\_number.rb** snip ... fields do number :string, :required => true # Hobo bug? see bottom of recipe timestamps end belongs_to :phone_kind belongs_to :profile belongs_to :agent belongs_to :client belongs_to :cooperating_agent validates_presence_of :phone_kind # Hobo bug? see bottom of recipe # The never_show line gets rid of extraneous fields that could otherwise # result in erroneous behavior. There is a residual bug here. I tried # to add :profile to the list. When I did, attempting to display the # phone number resulted in a Hobo error message decrying the attempt to # display a non-readable field. I will look at this further and if # necessary I will post a ticket and fix this recipe when possible. # Editing application.dryml as shown below gets rid of the profile field. never_show :agent, :client, :cooperating_agent def name number + ' ' + phone_kind.kind # minimal formatting - this could be fancier end # --- Permissions --- # snip ... **phone\_kind.rb** snip ... fields do kind :string timestamps end has_many :phone_numbers # --- Permissions --- # snip ... **profile.rb** snip... fields do name :string street :string sti_type :string # Add this timestamps end set_inheritance_column :sti_type # Add this has_many :phone_numbers # This is normal relationship children :phone_numbers # This was needed to make the phone_numbers appear. # --- Permissions --- # snip ... **agent.rb** class Agent < Profile # For STI # Leave out the hobo_model line. Without it, there is no tab for the class (e.g. Agent tab). # With it, the ^(*&% thing overflows the stack when creating, editing, etc. has_many :phone_numbers # The other recipe(s) say leave the sub-class models empty, but children :phone_numbers # I needed both these lines to make the app work. end Similarly for **client.rb** and **cooperating\_agent.rb**: class Client < Profile # Leave out the hobo_model line. Without it, there is no tab for the class (e.g. Agent tab). # With it, the ^(*&% thing overflows the stack when creating, editing, etc. has_many :phone_numbers children :phone_numbers end class CooperatingAgent < Profile # Leave out the hobo_model line. Without it, there is no tab for the class (e.g. Agent tab). # With it, the ^(*&% thing overflows the stack when creating, editing, etc. has_many :phone_numbers children :phone_numbers end Edit the controllers: **phone\_numbers\_controller.rb** class PhoneNumbersController < ApplicationController hobo_model_controller auto_actions :all, :except => :index # I didn't want the Phone Numbers tab to be visible auto_actions_for :profile, :create # These were required to get the auto_actions_for :agent, :create # Add Phone Number link to auto_actions_for :client, :create # appear on all of the show pages auto_actions_for :cooperating_agent, :create end **profiles\_controller.rb** class ProfilesController < ApplicationController hobo_model_controller auto_actions :all, :except => :index # I didn't want the Profile tab to be visible end Edit **application.dryml # Add this at an appropriate place (I put it at the end).

Home

Edit Phone number <! ################################################################################## Removing the following line eliminated another (not Available) link-substitute. I don't know where it came from since profile doesn't have a description field. ################################################################################## -->  This edit was necessary (1) to remove the "profile" field which could have caused erroneous behavior. Removing it via the never\_show method failed with a Hobo error; (2) to add back the missing menu tabs, and; (3) To remove extraneous (Not available) link-substitutes associated with profile. Once you have done the above, then: hobo generate migration rails server I have not been able to get the appropriate tabs for the sub-classes to appear without causing a stack overflow when performing db operations on the sub-classes. With the exception of that, everything works if you use the appropriate route (e.g. localhost/clients, or localhost/agents). In my app, I just manually modified the main menu to include tabs for the sub-classes as shown in application.dryml above. There is minor exception to it working as expected: when the validation for the phone number fails during create or edit, there is **NO notification** to the user. It just silently re-loads the failing page. I think this is a bug in Hobo, but I haven't investigated any further yet.

Hobo with Paperclip - storage to db column.

2011-01-05T17:40:32Z

After installing **Paperclip**, getting it to work, and searching for the uploaded data I decided to RTM and found that I had two choices, storage on the file system (the default) or storage to s3. For business reasons (and the desire to eventually host on Heroku) I needed the data storage in the appropriate db tables. Kevin found **http://patshaughnessy.net/2009/2/19/database-storage-for-paperclip** for me (I never thought to Google for it). Pat Shaughnessy did a really good implementation for Rails 3.0 which I used in place of the original paperclip. After a few issues, I got it working on Ralis 3.0, Hobo 1.3, as follows: **First install the plain-vanilla paperclip and get it working (use the default file system storage for simple installation) so you are starting from a known good condition.** Then **Edit Gemfile** gem 'paperclip', :git => 'git://github.com/patshaughnessy/paperclip.git' I put this just after the hobo line: gem "hobo", ">= 1.3.0.pre25" Then **sudo bundle install** In my case, this overwrote the existing plain-vanilla paperclip with Pat's version. **Edit the model** (in my case agent\_documents.rb) adding/changing only two lines: document_file :binary # in the field definition block has_attached_file :document, :storage => :database #THIS DID NOT WORK AT FIRST! **hobo g migration ... THIS FAILED.** There is a chicken vs. egg problem here. The *has\_attached\_file* line is processed before the *document\_file :binary* field declaration which leads to an undefined method error. The solution is to **first comment out the , :storage => :database**, then **hobo g migration** This time it works. Now **un-comment ", :storage => :database"**, restart your server and have fun uploading attachments. Now for the download: **Edit the controller** (in my case agent\_documents\_controller.rb), adding: downloads_files_for :agent_document, :document the first argument is the name of the model, the second is the attachment name as generated by paperclip. **Edit routes.rb**, adding: match 'agent_documents/documents/:id' => 'agent_documents#documents' at the appropriate priority level (mine was low so I put it at the end). Lastly, **insert the link** in your appropriate dryml file. In my case, I added it to views/agent_documents/show.dryml: View Document or View Document My memory is going. I created (plagiarized and modified I think) the nav-item-external tag, but forgot about it, so anyone who implements this will get an error. The definition (and the similar a-external tag) is: /, '').strip -%>

/, '').strip -%> In my case, I put both of these in app/views/taglibs/internet_nav.dryml

Full stack testing a Hobo Application

2010-12-04T02:53:08Z

Reuse of DRYML and controller logic in Hobo allows us to apply the same test pattern for all the controllers in the project. Roll your application complete with functional and acceptance tests. RSpec, Steak, Capybara, FactoryGirl and Shoulda are hands-on demonstrated on a project: __[Full stack testing a Hobo Application](http://conceptspace.wikidot.com/blog:all-about-testing-hobo-organizations-revisited)__

Hobo on Amazon EC2

2010-11-05T18:32:27Z

A minimal setup guide to getting Hobo running on a Tiny 32 bit Linux EC2 instance. sudo yum erase ruby sudo yum groupinstall 'Development Tools' sudo yum install readline-devel bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ) rvm package install openssl rvm install 1.9.2 --with-openssl-dir=$HOME/.rvm/usr gem install sqlite3 gem install rails -v 2.3.5 gem install hobo Enjoy!

incompatibilti ç, help me

2010-11-02T05:22:56Z

after install "hobo" I tried ran exmaple "hobo agility" but shown thats,..... lord@lord-desktop:~/projects$ hobo agility Generating Rails app... /bin/bash: -S: invalid option Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --protected --rcfile --restricted --verbose --version Shell options: -irsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option /usr/lib/ruby/gems/1.8/gems/hobo-1.0.1/bin/hobo:96: private method `split' called for nil:NilClass (NoMethodError) from /usr/bin/hobo:19:in `load' from /usr/bin/hobo:19 lord@lord-desktop:~/projects$ What it is=?

Instant Front End: Just Add Schema to Hobo

2010-10-26T09:58:55Z

My personal holy grail of web programming is to take any database and then convert it into a CRUD complete webstie at the click of a button. Yesterday I realized I could get half way there with little effort using tools I already have. I used my old friends sed and awk to parse a rails schema into hobo generator format. Here is the ruby script I came up with (you have to manually set the rails version for now): #!/usr/bin/ruby require 'rubygems' require 'active_support/inflector' RAILS_VERSION = 2 schema = `cat #{ARGV[0]} | sed '/#/d' | sed '/ActiveRecord/d' | sed '//d' | sed '/add_index/d' | awk '{print $2":"$1" "}'` schema.gsub!(/t\./,'') schema.gsub!(/,/,'') schema.gsub!(/\"/,'') xs = schema.split(/\n/) xs.delete_if {|line| line[0] == 58} xs.map! do |line| if(line[/create_table/]) line.gsub!(/.create_table/,'').chop! line = line.pluralize.singularize if(RAILS_VERSION < 3) $/ + "script/generate hobo_resource " + line + ' ' else $/ + "rails generate hobo:resource " + line + ' ' end else line end end puts xs.to_s Run the above script on a schema file dumped by rake (rake db:schema:dump while connected to the target database): ActiveRecord::Schema.define(:version => 20101025160107) do create_table "addresses", :primary_key => "addressid", :force => true do |t| t.string "street", :limit => 100 t.string "postcode", :limit => 100 t.string "townname", :limit => 100 t.string "provincename", :limit => 100 t.string "homephonenumber", :limit => 100 end end Output: Rails 2.X script/generate hobo_resource address street:string postcode:string townname:string provincename:string homephonenumber:string Rails 3.X rails generate hobo:resource address street:string postcode:string townname:string provincename:string homephonenumber:string

Setting up unix like permissions with hobo

2010-08-10T21:36:02Z

For any unfamiliar with unix permissions, the basic concept is that each file, or in our case model instance, has an owner and group. There are independent permissions for owner, group and everyone on read, write, and execute. Because of the way hobo and rails work, I used view, write (update) and destroy. Now, most of the work for this actually has to exist in the model instance. So, to keep this DRY, we'll setup a module to handle the basic logic of permission and count on overriding for any exceptions. http://gist.github.com/517863 has the module I ended up writing. Save it in a file called unix_permissions.rb in app/models/ For it to work, it has to be included for one and there has to be a group model and user instances can have many groups. script/generate hobo_model_resource Group name:string script/generate hobo_model_resource GroupUser In `app/models/user.rb` add has_many :group_users has_many :groups, :through => :group_users, :accessible => true `app/models/group_user.rb` belongs_to :user belongs_to :group `app/models/group.rb` has_many :group_users has_many :users, :through => :group_users, :accessible => true `app/controllers/group\_users\_controller.rb` auto_actions :write_only Note: only one of the group or user needs ability to add links technically. Add these new tables and columns to the db `script/generate hobo_migration` At this point, you could add `include UnixPermissions` to a model(s), remove the default permission methods and have it work (mostly). You'll want to clean up the views as by default it will show each of the permissions that's true on the model show page. And likely move group/user administration to a subsite. Remember, any of the methods defined here can be overridden just by redefining the method after the include UnixPermissions call. Say for instance, you don't want anyone able to destroy a particular model: include UnixPermissions def destroy_permitted? false end Obviously, this is not a perfect solution for all situations but should give you a starting point or some ideas for writing your own.

How to get full text search working with Sunspot

2010-08-06T19:25:12Z

Basically we'll be following [sunspots quickstart guide](http://wiki.github.com/outoftime/sunspot/adding-sunspot-search-to-rails-in-5-minutes-or-less) with a couple of tweaks for hobo. ## Setup a hobo app For this, I'll make the, at this point, stereotypical blog application. hobo search_demo cd search_demo ./script/generate hobo_model_resource Post title:string body:text script/generate hobo_migration ## Install Sunspot and dependencies > First, you’ll need to install Sunspot::Rails, which integrates Sunspot search seamlessly into your Rails app. This will install Sunspot > and RSolr as dependencies. > > `$ sudo gem install sunspot_rails` > > Add it to your config/environment.rb: > > `config.gem 'sunspot_rails', :lib => 'sunspot/rails'` > > Run the generator to create the config/sunspot.yml file: > > `$ script/generate sunspot` > > To get the Sunspot rake tasks, you’ll need to require the tasks from your app’s Rakefile: > > `require 'sunspot/rails/tasks'` > > Now it’s time to start Solr. Solr is a standalone HTTP server, but Sunspot comes packaged with a copy of it that’s already configured to > work with Sunspot; use the rake task to fire it up: Here's where I diverge from their path and add in that you need to copy the solr/conf and solr/lib directories from the gem installation directory if you have run `acts\_as\_solr` in the past. That or delete the solr/ directory from your app before running this next command. > `$ rake sunspot:solr:start` > > The first time you run this command, it will create a solr/ directory in your Rails root. This contains Solr’s configuration, as well as > the actual data files for the Solr index. You’ll probably want to add solr/data to your .gitignore. If you later would like to play > with Solr’s configuration (e.g., customizing the filter chain for text fields), you’ll find the configuration files in solr/conf. ## Tell sunspot what to index Add this to your Post model searchable do text :title, :default_boost => 2 text :body end This tells sunspot to index the post model, with full text searching on the title and body fields with title matching being twice as relevant by default. Now, tell sunspot to index any existing post data. You can skip this step if you have a blank application and instead add a few posts. `$ rake sunspot:reindex` ## Adding search to your controller Here, we'll diverge a little because Hobo makes this easier for us. We're going to add the search to the normal index method if a query parameter is supplied. class PostsController < ApplicationController hobo_model_controller auto_actions :all def index if params[:query] @posts = Post.search do keywords(params[:query]) paginate(:page => (params[:page] or 1), :per_page => 10) end.results @posts.member_class = Post else hobo_index end end end A quick explanation is in order, Post.search is sunspots search method. The block describes how to search and return results. Right after the block, the .results is not a typo. Sunspots search method returns a search type object with search scores and objects but for a quick and dirty search, we're just interested in the, well, results. Now, we can actually test this out at this point by going to `http://localhost:3000/posts?query=someword`. Be sure to pick a word you know is in at least 1 but not all posts. Obviously we can't leave it like that for the end user but we're most of the way there. ## Add search to view We need to tweak the index page to show a search box. `app/views/posts/index.dryml` Search Posts And have the controller save the query parameter for the view by changing the if line as follows. `app/controllers/posts_controller.rb` + if @query = params[:query] - if params[:query] And now search is easily accessible. Exercises left for the reader: * possibly change live-search box to use sunspot or remove entirely from view * explore other Post.search options to increase usefulness * perhaps each post has an owner and/or comments that you want to search to include. add these to the searchable method in the Post model * this isn't production ready as you'll want a separate solr server that isn't the one bundled with sunspot

Setup Ruby-debug

2010-08-03T18:45:57Z

A good practice for getting acquainted with code, and pinning down issues in the code you write, is to use a debugger. In many languages, we would have to setup an IDE to accomplish this. In Ruby, however, there exists a good gem for accomplishing the same task. ## Setup ## * Install the ruby-debug gem: > gem install ruby-debug * Note: the ruby-debug gem is a native gem, and won't yet compile on Ruby 1.9.1. There isn't any really good reason to be running Hobo on 1.9.1 (other than speed), so I'm going to assume this isn't an issue for most. * Add the gem to your Rails environment: * Open project_name/config/environment.rb * Right under Rails::Initializer.run do |config| enter "config.gem 'ruby-debug'" (without the double-quotes) * Open project_name/config/environments/development.rb and add to the bottom of the file: > require 'rubygems' > require 'ruby-debug' > Debugger.start * Reboot your Rails server and debug mode is enabled. To use it, just add "debugger" (again, without the quotes) to anyplace you would normally put ruby code. If you are trying to look at something in the view layer, enter the following: > Be sure not to use the ll update any confusing sections.

Children Viewhint and Paginate

2010-07-28T13:40:30Z

Intro

If you have models with belongs\_to and has\_many relationships and have used the children view hint on the parent model, you will get a collection of cards on the bottom of the main page or on the sidebar depending on how many child models you specify and in what order. See () for more information on this behavior. You may have noticed, however, that automatic pagination does not happen. :-( It would be nice if the children viewhint supported parameters that would enable this. Maybe the author of the generator spitting out the Rapid show page is reading this...heck, I might try a hack of it myself. But until then, there are two ways to support this behavior. This recipe documents them.

Prerequisites

Create a demo app. $ hobo paginate_children

Create models

Let's create models that support parent/children relationships. How about Post and Comment? $ cd paginate_children $ ruby script/generate hobo_model_resource Post name:string $ ruby script/generate hobo_model_resource Comment name:string Edit the models to define the parent/child relationship.

paginate_children/app/models/post.rb

class Post < ActiveRecord::Base hobo_model # Don't put anything above this fields do name :string timestamps end + has_many :comments # --- Permissions --- # def create_permitted? acting_user.administrator? end def update_permitted? acting_user.administrator? end def destroy_permitted? acting_user.administrator? end def view_permitted?(field) true end end

paginate_children/app/models/comment.rb

class Comment < ActiveRecord::Base hobo_model # Don't put anything above this fields do name :string timestamps end + belongs_to :post # --- Permissions --- # def create_permitted? acting_user.administrator? end def update_permitted? acting_user.administrator? end def destroy_permitted? acting_user.administrator? end def view_permitted?(field) true end end

Add children viewhint

paginate_children/app/viewhints/post_hints.rb

Add the viewhint for comments to the post model. class PostHints < Hobo::ViewHints # model_name "My Model" # field_names :field1 => "First Field", :field2 => "Second Field" # field_help :field1 => "Enter what you want in this field" # children :primary_collection1, :aside_collection1, :aside_collection2 + children :comments end

Overriding will_paginate default per_page value

In order for us to be able to see pagination work with only a few child entries, use this monkey patch to change the default per\_page value from 30 to 3. Add this code to the end of paginate\_children/config/environment.rb: # Set will_paginate default per_page to 15 instead of the default 30 ActiveRecord::Base.instance_eval do def per_page; 3; end end

Startup

Migrate your models and startup the server. $ ruby script/generate hobo_migration ... $ ruby script/server At this point, you should be able to add the administrative user. Go ahead also and add a post and add 4 comments attached to that post.

Two techniques

There are two techniques to achieve this. 1. You create a paginated collection instance variable in the post controller and then override the show page to use this variable. You also have to add the paginate tags so the pager controls show. 2. Use the index owner action on the comment controller.

Collection instance variable

We need to set up pagination for the comments collection. Add a comments instance variable to the posts\_controller.

paginate_children/app/controllers/posts_controller.rb

class PostsController < ApplicationController hobo_model_controller auto_actions :all + def show + hobo_show do + @comments = this.comments.paginate(:page => params[:page]) + end + end end Next, override the comments collection in the Post show page to use the instance variable just created and add the paginate tags.

paginate_children/app/views/taglibs/application.dryml

Paginate Children + + + + + + + + +

Test it out

If you added 4 or more comments to a post, that post's show page should show those comments paginated with 3 entries per page.

Index owner action

You can get pagination behavior out of the box by using the index owner action on the comment controller as defined below.

paginate_children/app/controllers/comments_controller.rb

class CommentsController < ApplicationController hobo_model_controller auto_actions :all + auto_actions_for :post, [:index] end You can the use the url http://localhost:3000/posts/:id/comments to access the show page for the post id referenced by :id. The comments collection will be paginated (and note that this is not because of the code from technique 1...see app/views/taglibs/auto/rapid/pages.dryml and look for index-for-post-page). The problem with this technique (unless I am missing something) is that the wiring up of the navigation to this url is not done by the framework automatically.

jqGrid on Hobo

2010-07-19T18:00:14Z

About a year ago I started working with hobo and really liked what I saw. I could do some amazing things really fast. The only piece that felt like it was missing something was the table-plus tag. So I started working on an alternative and decided to start from the well known jqGrid widget. I went on to install every rails jqGrid plugin in existance and found that none of them were quite what I wanted. The main features of my incarnation of the jqGrid plugin are: - Uses a rails model directly instead of the limiting auto-detect method - Uses a randomly generated id name so you can put as many grids of the same or different types as you want on the same page - Direct editing of the jqGrid properties through hash properties e.g. :title => "Title" - Easy to edit default jqGrid properties (plan to take it a step further and implement them as yaml later) - Uses the # symbol as the first character to identify a function property (I implemented the ondblclickrow property this way) - Double clicking on rows and anything else that is possible with the jqGrid widget... ##[rails-jqgrid @ Github](http://github.com/allen13/rails-jqgrid) This is a rails plugin dedicated to the great jqGrid javascript widget. I had two rails concepts in mind when I created it, "DRY it up" and "Convention over configuration". I managed to get jqGrid to work with two lines of code ( one if you don't count the styling). A standard set of grid options has already been defined, so all you really need to do is give it a model. Enjoy :-) Usage Instructions: #For the jQuery grid theme #For the grid Example: "exercise_type,duration_in_mins,date") %> Copyright (c) 2010 [name of plugin creator], released under the MIT license

Remembering Filter Parameters

2010-07-08T05:43:08Z

When you are using a `` on an index page, it is often nice to be able to remember the filter parameters that the user had set. This allows the user to wander off to other pages and have their filter parameters restored when they subsequently return to the index page. For example, in a work tasking application, users use filters to select the subset of tasks from the task list that they wish to work on. Working on each task takes the user away from the index screen. When they have completed the task and return to the index screen, their filter parameters would normally have been reset and they now need to reselect their subset of tasks they are working on. It is much more user friendly to have the filter parameters to remain in use in the current session until they explicitly change them. There are two parts to the solution. First, you need to save the filter parameters. In the `index` action in the controller, add the lines: filter_parameters = request.parameters filter_parameters.delete(:controller) filter_parameters.delete(:action) session[:filter_parameters] = filter_parameters This gets the parameters from the request, strips out the action and controller, and then stores them in the session hash. When ever the filter parameters are changed, they are stored in the session. This also works with pagination, so the user will return to the page of results they were last on - just strip out the `page` parameter if you don't want this. Secondly, we need to restore them when the user returns to the index page. We do this using the assumption that there is only one path to the index page, namely through the navigation bar. The filter parameters are restored by appending them to the url of the index page with: Surveys The `params` attribute of the `` tag converts the hash to a http parameter string and attaches it to the end of the url. Now when the user clicks on the nav item in the nav bar, they will return to the index page just how they had left it.

Hierarchies - Using acts_as_tree

2010-06-27T23:33:02Z

Intro

The acts\_as\_tree gem () provides support for organizing rows in a table into a parent/child hierarchy. This is useful for structures where entries have subentries and so on. Category listings often have this structure. Hobo does not have native support for this gem, so this is my attempt to add some support. I welcome feedback on how to make this more flexible/usable.

Prerequisites

First, you need to get the acts\_as\_tree gem. $ sudo gem install acts_as_tree Now create a demo app. $ hobo tree_demo Add the gem to your environment.rb so that the gem autoloads into your application at startup.

tree_demo/config/environment.rb

# Be sure to restart your server when you modify this file # Specifies gem version of Rails to use when vendor/rails is not present RAILS_GEM_VERSION = '2.3.8' unless defined? RAILS_GEM_VERSION # Bootstrap the Rails environment, frameworks, and default configuration require File.join(File.dirname(__FILE__), 'boot') Rails::Initializer.run do |config| config.gem 'hobo' + config.gem 'acts_as_tree' ...

Create a model

Let's create a model of Categories that support's parent/child relationships. $ ruby script/generate hobo_model_resource Category name:string parent_id:integer Edit the new model to define the hierarchical relationship.

tree_demo/app/models/category.rb

class Category < ActiveRecord::Base hobo_model # Don't put anything above this fields do name :string parent_id :integer timestamps end + acts_as_tree :order => :name # --- Permissions --- # def create_permitted? acting_user.administrator? end def update_permitted? acting_user.administrator? end def destroy_permitted? acting_user.administrator? end def view_permitted?(field) true end end Migrate the model modification and start the server. $ ruby script/generate hobo_migration ... $ ruby script/server

Add new tag definition

Add the following tag definition to a new tag library. This new tag displays a hierarchical unordered list of a model that has acts\_as\_tree defined. Credit to for the original code snippet to do this. I adapted it to work with hobo.

tree_demo/app/views/taglibs/tree.dryml

0 %>

0 %>

(none)

Modify view to display hierarchy

Open up the applications.dryml file. We are going to override the default categories index page and replace the collection of Categories with the new links-for-tree tag. You also have to add an include for the new tag library file created that contains the links-for-tree tag.

tree_demo\app\views\taglibs\application.dryml

+ Tree Demo + + + + + + +

Test it out

Go to the Categories link and add some new categories. Be sure to add subcategories and set up their parent. When you go back to the Categories index page, you should see a hierarchy list of links to categories instead of a flat collection.

Further steps

Relationships

The links-for-tree tag supports index\_for\_\* relationships, meaning that if you pass the 'to=' attribute, where 'to' represents the name of a has\_many relationship on the passed in context, then the links that will be rendered will be links to the related object that belongs to the context. For example, if Tasks belong to a Category, and you wanted to create a Category side bar on the Tasks index page that would link to index\_for\_category to narrow the scope to show only those tasks that belong to the clicked category, you would code:

New collection tag

After writing this tag, it occurred to me that the existing collection tag (or perhaps a new one) could be modified to show categorized cards that belong to a model that has a parent/child relationship. I could envision some jQuery magic that would roll down/up sections that contain cards by clicking on the model names of the hierarchical relationship. For next time...

Integrating Google Maps with Hobo

2010-05-25T01:34:04Z

Integrating Google Maps into a Hobo application is very simple. The [YM4R](http://ym4r.rubyforge.org/) plugin does all of the heavy lifting of generating the necessary Javascript. #### Install YM4R/GM ruby script/plugin install svn://rubyforge.org/var/svn/ym4r/Plugins/GM/trunk/ym4r_gm #### Set up a Google Map Tag In application.dryml, define the following tags: true,:map_type => true) @map.center_zoom_on_points_init([ne_lat,ne_long],[sw_lat,sw_long]) %> width, :height => height) %> title, :info_window => info)) %> The attributes for google-map are: * id - the id assigned to the div element containing the map. Different maps on the same page should have a different id. * ne-lat, ne-long, sw-lat, sw-long - the map will be automatically scaled to contain a bounding box defined by these two points * width, height - the size of the map to display. Any HTML units of measurement are accepted. The maker tag places markers on the map. Its attributes are: * lat, long - the location of the marker * title - displayed as a tooltip when you mouseover the marker * info - HTML code displayed in a popup when you click on the marker #### Insert a Map in a Page Each page containing a map first needs the Google Maps Javascript library included: Then to create the map: #### A More Complex Example I have number of sites as defined by the model: class Site < ActiveRecord::Base hobo_model # Don't put anything above this fields do code :string, :required, :unique, :name => true site_name :string, :required latitude :decimal, :precision => 15, :scale => 10 longitude :decimal, :precision => 15, :scale => 10 timestamps end belongs_to :district end where each site has a code, site name and belongs to a geographical district. The index.dryml page to display these sites on a map is:

District:

No sites match your criteria The index page will display all of the site locations on a map and scale the map to right size to contain them all. Note - some of my sites don't have location data so I filter them out from the map. The user is able to filter the list of sites using the table-plus filter and the map will only display those sites. The corresponding controller is: class SitesController < ApplicationController hobo_model_controller auto_actions :all def index scopes = {:search => [params[:search], :site_name], :district_is => params[:district], :order_by => parse_sort_param(:code, :district, :site_name)} hobo_index Site.apply_scopes(scopes), :include => [:district], :paginate => false end end One downside is that the map will only show those sites that are displayed on that page, so if you have more than one page of results you will need to turn off the paginator with :paginate => false. YM4R has a number of other features including geocoding and getting maps from other providers such as Yahoo and Microsoft. #### Google API Key Google allows you to embed a map in your application freely if it is accessed locally at http://localhost. If your application is available remotely, Google requires you to register at [http://code.google.com/intl/en/apis/maps/signup.html](http://code.google.com/intl/en/apis/maps/signup.html) and obtain an API key for your site. Your API key for each address needs to be recorded in config/gmaps\_api\_key.yml

Using Highslide with Hobo

2010-05-18T15:04:16Z

[Highslide](http://highslide.com/) is another powerful image, media and gallery viewer written in JavaScript that is really easy to integrate with Paperclip in Hobo. Download Highslide from [http://highslide.com/](http://highslide.com/) and unzip the file in the public directory of your application. In your application.dryml add the following: /highslide/graphics/'; hs.showCredits = false;

Using Lightbox with Hobo

2010-05-02T23:46:35Z

[Lightbox] (http://www.huddletogether.com/projects/lightbox2/) is a simple, unobtrusive script used to overlay images on the current page that is used on many web sites and integrates well with Paperclip. Using Lightbox with Hobo is very straight forward. #### Install Lightbox Download the code from [http://www.huddletogether.com/projects/lightbox2/](http://www.huddletogether.com/projects/lightbox2/) Copy builder.js, scriptaculous.js, lightbox.js to public/javascripts in your Hobo project. Copy lightbox.css to public/stylesheets in your Hobo project. Copy the contents of images to public/images in your Hobo project. #### Include the Lightbox Javascript and Stylesheet In application.dryml, extend the page tag to include the Lightbox javascript and stylesheet. #### Fix a Couple of Issues In lightbox.js, change the following line: LightboxOptions = Object.extend({ fileLoadingImage: '/images/loading.gif', fileBottomNavCloseImage: '/images/closelabel.gif', In lightbox.css, change the following line: #prevLink, #nextLink{ width: 49%; height: 100%; background-image: url(data:image/gif;base64,AAAA); /* Trick IE into showing hover */ display: block; background-color: transparent; border: 0} #### Modify the Card Tag for Images In your application.dryml, extend the Card for images: This card will display the thumbnail of images uploaded using Paperclip and display the larger version when the user clicks on it. When showing a collection of images, clicking on a thumbnail with present a slideshow of the collection that the user can page through. Images can have a title included by adding a title= attribute to the < a > tag.

Routing from specific domain or host

2010-04-09T12:16:57Z

If you need, like me, routing something using specific domain or host, just create a file under

yourapp/config/initializers

a file like this:


module ActionController

  module Routing

    class RouteSet
      def extract_request_environment(request)
        env = { :method => request.method }
        env[:domain] = request.domain if request.domain
        env[:host] = request.host if request.host          
        env
      end
    end

    class Route
      alias_method :old_recognition_conditions, :recognition_conditions
      def recognition_conditions
        result = old_recognition_conditions
        result << "conditions[:domain] === env[:domain]" if conditions[:domain]
        result << "conditions[:host] === env[:host]" if conditions[:host]        
        result
      end
    end

  end

end

Now, you're be able to use this in your routes:

map.connect '', :controller => 'admin/front', :action => 'index', :conditions=>{ :domain=>'admin.yourdomain.com' }

Using multiple 's for the same model on the same page

2010-04-09T04:32:00Z

Suppose you have a list (of requests for example) that are partitioned into a number of sublists that you want to be able to reorder individually on some page. Using the requests, example, the Request model might look like this: class Request < ActiveRecord::Base hobo_model # Don't put anything above this belongs_to :project acts_as_list :scope => %q(project_id = #{project_id} and priority = '#{priority}') fields do title :string, :required priority enum_string(:high, :medium, :low), :required, :default => 'medium' timestamps end validates_uniqueness_of :title, :scope => :project_id end Since we said that requests belong to projects, we better add some has_many's to the Project model: has_many :requests, :dependent => :destroy has_many :high_priority_requests, :class_name => 'Request', :conditions => {:priority => 'high'} has_many :medium_priority_requests, :class_name => 'Request', :conditions => {:priority => 'medium'} has_many :low_priority_requests, :class_name => 'Request', :conditions => {:priority => 'low'} And, to get the requests automatically displayed on the project page, we need the following in the projects viewhints file: children :requests Now, we are ready to replace the whole list of requests with three sublists: one each for the low, medium and high priority requests. We create a show page for projects that looks like:

High Priority Requests

Medium Priority Requests

Low Priority Requests

Note that we had to create a different div id for each of the sublists, because these id's are required to be unique on the page. However, hobo uses the div id as the parameter to specify how the elements were reordered. Thus, we add the following method to the Requests controller: def reorder # We need to (un)distinguish the high, medium & low priority request sections request_ordering = params.keys.grep(/request_ordering$/)[0] params['request_ordering'] = params[request_ordering] hobo_reorder end Now, the application can the multiple <sortable-collection>'s for the same model on the same page.

Using GMail for Sending Email

2010-03-28T06:37:43Z

If you enabled **GoogleApps** in your Domain. You might want to take advantage of sending email using **Gmail**. You just need to do the following simple steps. This is very useful specially when your using **--invite-only** option when creating your hobo application. Let's start rolling. You need to install the following gem. If your using heroku as your staging server or even production server you might want to include this on your **.gems** file: Install the gem in your local machine: sudo gem install tlsmail Again if your using heroku, add the following line in your .gems file: tlsmail --version '>= 0.0.1' Now that you have the gem in place it's time to add other configurations: Your **environment.rb** should look like this: Rails::Initializer.run do |config| config.gem "tlsmail" ... end Net::SMTP.enable_tls(OpenSSL::SSL::VERIFY_NONE) Add the following lines in your **environments/development.rb** or **environments/production.rb**: config.action_mailer.delivery_method = :smtp config.action_mailer.smtp_settings = { :address => "smtp.gmail.com", :port => "25", :domain => "your_domain.com", :user_name => "your_login@your_domain.com", :password => "your_password", :authentication => :login } That should be it. If you do: git push heroku master It will automatically install the gem in your heroku instance, then you should be able to send invites or better yet send email from your hobo application. Thanks to: **http://codelikezell.com/using-gmail-with-rails/** for this guide.

Customized the Select Menus In A Hobo Form

2010-03-09T18:27:29Z

Hobo does a nice job of generating a default form for every model you generate. Especially nice are the "select" boxes that follow ActiveRecord "belongs\_to" associations. In any event generally speaking the best way to look at how to change the form for a model is to look at the autogenerated tag created by Rapid, in $RAILS_ROOT/app/views/taglibs/auto/rapid/forms.dryml There you'll see this (basically):

Now lets monkey with this tag a bit. For my model I have a belongs\_to association called "group leader" that I want to filter, or put another way I want to restrict the entries that can appear in my dropdown. Here's the bit from the model code: class InviteGroup < ActiveRecord::Base hobo_model # Don't put anything above this fields do name :string group_leader_id :integer address :text timestamps end has_many :invitees belongs_to :group_leader, :class_name => 'Invitee', :foreign_key => "group_leader_id" ..... In this case I only want to allow a group leader who is actual an invitee of this group. So if an invite doesn't point to this group, it can't be my leader. Put generically: A foreign key to a parent table may have a restricted set of valid values. Lets restrict our form, in this case to whatever the 'invitees' method of our current object returns. We can do this by 'extending' our form tag, and we'll do this by altering the behaviour of the tag in $RAILS_ROOT/app/views/taglibs/application.dryml Explained simply: - extend alters the tag auto-generated by rapid - old-form merge; see the agility tutorial more on this construct - group-leader-view ; we can change the markup generated for any field in field list This works like a charm! How to learn more? Probably the best thing you can do is work through the DRYML guide; this will help you crack the mystery of these tags and empower to alter the functionality of the Rapid tags, as well as write your own. Good luck!

Ajax login form

2010-02-21T21:50:15Z

(Note that this recipe requires Hobo 1.1 or the latest version from [github](http://github.com/tablatom/hobo)) On a recent site I worked on, we wished to be able to create an order without logging in. The solution we came up with was to replace the "save" button with an ajax login form. Typically, AJAX forms are trivially easy to do in Hobo, but there's a few things that made this recipe a little less trivial. 1. HTML does not allow nested forms, so the login form is actually placed outside of the order form. 2. We moved the flash messages to ensure that users still received login failure messages. 3. Hobo only updates a single part after AJAX. In our scenario, we had two portions that needed updating -- the actions parameter in the form and the div after the form. Usually you can just update all or most of the page when you have several portions to update, but we didn't want to lose the user's order. Instead, we used Javascript for the second update. 4. In our application, Orders are created via a lifecycle method called "initiate". However, guests are not allowed to trigger the method. So the generated initiate-form does not work. However, `` does. Here's the DRYML:

and the Javascript: guestOrderLogin: function() { jQuery('.actions').removeClass('hidden'); }

navigation menu with more than 5 items

2010-01-24T17:47:30Z

For most applications, one of the first things that is done is to replace the navigation menu with a full custom menu. However for some applications like admin subsites, the standard navigation would be fine, if it wasn't limited to 5 items. Put this in your `application.dryml` (or `admin_site.dryml`) for a navigation that isn't limited to 5 items. Home

Optimistic Locking in Hobo

2009-11-27T07:41:17Z

A rarely used feature of activerecord is the lock\_version column, which (if present) enables optimistic locking for that table. When activerecord updates that model it will compare the lock\_version of the version being saved against the version in the database, and if they aren't the same then it will throw a StaleObjectError, which prevents concurrent updates from overwriting one-another. If they do match then the lock\_version is incremented (it's an integer) to invalidate any updates that are waiting to happen. This is a great way of increasing the safety and (potential) concurrency of your app (without needing more traditional concurrency schemes like table locking). To implement this in your hobo app you need to do update all 3 layers of your model (the model, view and controller). # Model This part's easy, just add lock\_version as a field in your models (and obviously generate a migration to add it to the database as well). class ConcurrentModel < ActiveRecord::Base hobo_model # Don't put anything above this # --- Fields --- # fields do lock_version :integer, :default => 0 timestamps end never_show :lock_version end Note that I've set the default to 0 (this is important or activerecord won't have a value to compare against when it updates). Also, the never\_show macro is useful because it hides the field from rapid (so it won't appear in any of your views) # View Next you'll need to add it to your forms so that when the user submits an update the server is sent the lock\_version that was current when they loaded the model. Thanks to rapid you can extend the form tag itself and this change will be reflected in every form rendered in your app. Here I've added lock_version to the input-many tag as well as the form tag - this is because input-many doesn't re-use form, but instead just calls field-list on any associated models. (Otherwise models updated through an input-many wouldn't be protected by optimistic locking). # Controller At this point optimistic locking will work, but the user will get a nasty error screen if a StaleObjectError is thrown. To correct this, you'll need to update your controller to catch the error, then reload the model (with the updated values) and send them back to the previous page in the same way as a validation error would. def update hobo_update rescue ActiveRecord::StaleObjectError flash_notice "This #{model.view_hints.model_name} was changed by someone else while you were editing it. Please try again." response_block(&block) or respond_to do |wants| wants.html do # reload the model from the database self.this = find_instance # re-render the form re_render_form(:edit) end wants.js do render(:status => 500, :text => ("There was a problem with that change.\n" + @this.errors.full_messages.join("\n"))) end end end end If you like you can override the update method in hobo itself and get this across all of your models. And that's it! Now your users will get a nice, user-friendly flash notice if they try a concurrent update, whereas before they would have silently overwritten someone else's update. To test it, try opening the same edit page (for the same model) twice in two different browsers (as you can have a different session in each). Change a few fields in both, then save them both (without reloading either after saving). The second one to be saved will show the warning above and reject the update. The idea for this recipe came from [Scripted Zen](http://scriptedzen.blogspot.com/2007/08/optimistic-locking-in-rails-with-active.html), which is one of the few places I've seen optimistic locking discussed (besides the pragmatic programmers rails book).

using a name-one one a model with a generated field for a name:

2009-08-26T18:03:21Z

Suppose you have a model that uses a generated field for its name: class User def name "#{first_name} #{last_name}" end end Now suppose that you have an `Institution` that `belongs_to :contact, :class_name => "User"`. And suppose you want to use a name-one to choose the contact: The next step is to autocomplete support to the users controller. I recently added support to `hobo_completions` to allow the completer to search more than one field. (In other words, this will not work with Hobo 0.8.8, you need 0.8.9 or edge Hobo) Let's take advantage of this: class UsersController < ApplicationController autocomplete :name, :query_scope => [:first_name_contains, :last_name_contains] end Now the autocompleter should work. However, if you submit the form, you get an error complaining that `find\_by\_name` doesn't exist. Let's fix that: class User < ActiveRecord::Base def self.find_by_name(name) names = name.split(' ') (0..(names.length-2)).inject(nil) do |result, n| result ||= self.find_by_first_name_and_last_name(names[0..n].join(' '), names[1..(n+1)].join(' ')) end end The code is a little tricky simply because we wish to handle both "Vince van Vickel" and "Mary Sue Jones" appropriately.

Adding an RSS feed.

2009-08-25T19:01:30Z

This is mostly the same as standard rails. Hobo does shorten the controller side if you don't need any filtering. In your controller, add an index_action for your feed. index_action :rss Hobo index actions will paginate for html requests but by default do not for xml requests. Then add the view file under /app/views/controller/rss.builder xml.instruct! :xml, :version => "1.0" xml.rss "version" => "2.0" do xml.channel do xml.title "news" xml.link url_for(:only_path => false, :controller => 'posts') xml.description "news items" @posts.each do |post| xml.item do xml.title post.title xml.link url_for(:only_path => false, :controller => 'posts', :action => 'show', :id => post.id) xml.description post.body xml.updated_at post.updated_at xml.guid url_for(:only_path => false, :controller => 'posts', :action => 'show', :id => post.id) end end end end The above is from a feed I created for a posts controller. Substitute your fields as needed.

Using recaptcha in your Hobo Lifecycle

2009-08-06T08:43:33Z

The easiest way avoid having automated spam-bots creating zillions of fake accounts in your application is to put a [captcha](http://en.wikipedia.org/wiki/Captcha) on the signup page. [Recaptcha](http://recaptcha.net/) is a fantastically cool one because it: * Is a free service * Uses the responses to OCR books * Has an easy to use [Rails plugin](http://ambethia.com/recaptcha/files/README_rdoc.html) This is how to add this functionality to a Hobo lifecycle event (create or transition). We'll use the 'signup' create from the [Agility tutorial](http://cookbook.hobocentral.net/tutorials/agility) as an example. - Install the recaptcha plugin: script/plugin install git://github.com/ambethia/recaptcha - Sign up to [Recaptcha](http://recaptcha.net) and generate the keys for your site. - Add the keys you've generated to your environment.rb: ENV['RECAPTCHA_PUBLIC_KEY'] = 'REPLACE-WITH-YOUR-PUBLIC-KEY' ENV['RECAPTCHA_PRIVATE_KEY'] = 'REPLACE-WITH-YOUR-PRIVATE-KEY' - In application.dryml extend the form tag for the lifecycle event that you're protecting. For the signup create event, that would look like: The `recaptcha_tags` provides all the HTML needed to display the Recaptcha dialog. Here we're adding it _immediately after_ the other form fields. At this point you should be able to refresh the page and the Captcha should display. The result of the Captcha is ignored though. Nothing is protected. - In the controller for the model (eg users_controller.rb), add (or modify) the 'do_' method for the lifecycle action to verify the captcha prior to the actual hobo action being invoked. For signup, this should look something like this: def do_signup unless verify_recaptcha flash[:error] = "The Captcha words you entered weren't right." redirect_to :back return end hobo_do_signup end end Try it out, your lifecycle event should now be protected by a Captcha. You may have noticed that we didn't really do anything lifecycle specific in here. You could use the same technique described to Captcha protect any form. I just chose lifecycles because they were a common case.

Ajax filtering on a partially completed form

2009-08-03T19:00:32Z

This is a neat trick I picked up reading some of Tom's code. This is useful when you've got a form that renders differently depending on the state of some of the values in the form. For example, when the user selects "United States" as the country, you may wish to add a "state" field, rename "Postal Code" to "Zip Code", and modify the list of shipping options in a select box. You could use lifecycles to make this a two stage form, but this is a neat trick you can use if you want to keep it all in a single form. Write your view normally using one of the many different options Hobo gives you. In this example, I'm going to extend the form: In this case, I've created an order that varies the options available in the shipping-method drop down depending on the country. You'll also see that I've wrapped the whole form in a part. In your controller (replace Order with your model): def edit self.this = Order.new(params[:order]) if params[:order] hobo_show do hobo_ajax_response if request.xhr? end end def new hobo_create(Order.new(params[:order])) do hobo_ajax_response if request.xhr? end end In your application.js (replace order-part with your part and order\_country with your select's class): Event.addBehavior({ "select.order_country:change": function(ev) { Hobo.ajaxRequest(window.location.href, ['order-part'], { params: Form.serialize(this.up('form')), method: 'get', message: 'Please wait...' }); } }); There you go: fancy custom AJAX, without really writing any AJAX code. ### How it works: Normally, when you hit submit on a new item, it POSTs to a URL like /orders. We've added a lowpro javascript watcher that triggers on the CSS selector "select.order\_country:change" that submits the form as a ajax request to the current location (ie, /orders/new). In the edit controller action, instead of looking up the current value in the database, we create it from the parameters passed in. We don't save it, though! Then we invoke the standard hobo ajax mechanism that renders our part. Most standard hobo actions will do this automatically for you, but the standard hobo\_show and hobo_\new do not, so we add it in ourselves.

Getting an app working with new heroku.com (not herokugarden.com)

2009-07-24T20:13:02Z

## Generate your app ## There's two possible approaches, either using the hobo gem which is easy with Heroku's .gems file or by installing hobo as a plugin. Create your app if you haven't already hobo appname # or rails appname if you're going to install hobo as a plugin to be able to use edge hobo cd appname git init git add . git commit -m "Initial commit" Make a heroku app to push your changes heroku create # enter your credentials if prompted (first use only) As long as you run this within a git initialized directory, it will add a new remote of heroku git push heroku master Note: heroku does not have all versions of rails gem available by default. Current list as of this posting is rails (2.3.2, 2.2.2, 2.1.0, 2.0.2). Check http://installed-gems.heroku.com/ for most up to date list. If your most recent version isn't one of these, make sure to either update the .gems file (see next step) to include your version or change your config/environment.rb to reference one of those rails versions. ## Gem Installation ## Just add a file to the root of your app called .gems with the following: hobo -v '0.8.8' The -v '0.8.8' is optional but a good idea to specify the hobo gem version you wish to use so you don't accidentally grab a later version with breaking changes in it. Any other gems you might need go on separate lines. Check this .gems file into git. git add .gems git commit -m "Added gemspec file" git push heroku Heroku will pick up on the new .gems file and automatically grab appropriate gems. ## Plugin installation ## This is not much different than the regular hobo edge install but you can't use submodules with heroku.com at this point. cd vendor/plugins git clone git://github.com/tablatom/hobo.git rm hobo/.git -rf rm hobo/.gitignore cd ../../.. # back to your base app directory git add . git commit -m "Added hobo plugin." git push heroku ## Final notes ## Heroku does not automatically run migrations so you'll need to run heroku rake db:migrate if you add any migrations.

Using Tony Tomov's jqGrid with Hobo

2009-07-07T15:25:23Z

The hobo-jqi plugin supports using the jqGrid grid with Hobo. ####Some jqGrid features:#### * resizable columns * paging controls * crud functions * JQuery UI theming and many more see them at: [http://www.trirand.com/jqgrid35/jqgrid.html](http://www.trirand.com/jqgrid35/jqgrid.html) See a [screencast install/demo](http://www.screencast.com/t/7nCgbl5L3) To install the grid 1. go to the plugins directory: cd vendor/plugins 2. load the plugin from github: git clone git://github.com/blizz/hobo-jqi.git 3. go to the root directory of project: cd ../.. 4. run the install rake task: rake hobo\_jqi:install 5. add the following line to app/views/taglibs/application.dryml
<include src="hobo-jqi-all" plugin="hobo-jqi"/> 6. add this line to the header of an index page:
<jqi-grid-includes theme="smoothness"/> 7. add this line to the content section of an index page:
<jqi-grid id="jqgrid"/> 8. restart your server

Adding ferret search to a hobo application

2009-07-06T23:02:48Z

# Prerequisites # First, you need the ferret gem. $ sudo gem install ferret Next, let's create a hobo app to use with ferret. $ hobo ferret_app Now, we need the acts\_as\_ferret plugin. $ ruby script/plugin install git://github.com/jkraemer/acts\_as\_ferret.git # Setup the model # Let's make a model that will have a ferret index on it. $ ruby script/generate hobo\_model\_resource Post title:string body:text Now we'll tell ferret we want to have an index on the model and what fields we want indexed. ferret_app/app/models/post.rb class Post < ActiveRecord::Base hobo_model # Don't put anything above this fields do title :string body :text timestamps end + acts_as_ferret :fields => [:name, :body] + + def name + title + end # --- Permissions --- # def create_permitted? acting_user.administrator? end def update_permitted? acting_user.administrator? end def destroy_permitted? acting_user.administrator? end def view_permitted?(field) true end end Note: the only reason I used a method for name was to indicate that ferret can index on more than just columns. You can index any string a method returns so you can do indexes across complex joins or filtered text etc. Now let's have hobo generate the migration and start up the server. $ ruby script/generate hobo_migration ... $ ruby script/server Go ahead and create a user and add some sample posts. Remember, you'll need unique content for at least 1 or 2 of them as we'll be testing out a search function. # Test Searching # Start up a console and run a couple of queries. $ ruby script/console Loading development environment (Rails 2.0.2) >> Post.find_with_ferret('test') => [#] >> Post.find_with_ferret 'stranger' => [#] Ferret sorts it's results by relevance according to your search term. You can do things like set weights on particular fields to make say, posts that match title come up sooner than posts that just match in the body. # Pagination of Search Results # So, now we can get results but how do we get them paginated? This is likely to be a concern as if you're using ferret you most likely have more than just 10 rows (the default limit) in your table. To make pagination easier, we'll extend the ActsAsFerret module with a paginated search method. Create the following in a file: lib/ferret_pagination.rb module ActsAsFerret module ClassMethods def paginate_search(query, options = {}, find_options = {}) page = options[:page] || 1 per_page = options[:per_page] || 10 total = options[:total_entries] pager = WillPaginate::Collection.new(page, per_page, total) options.merge!(:offset => pager.offset, :limit => per_page) result = find_with_ferret(query, options, find_options) returning WillPaginate::Collection.new(page, per_page, result.total_hits) do |p| p.replace result end end end end This is modified from a post describing how to do pagination with ferret to work properly with hobo and WillPaginate. Note: this might not be necessary given the new find\_with\_ferret method that returns results similarly to normal finder methods. Add a line to your environment.rb file to load in the new file. config/environment.rb ... +require 'ferret_pagination.rb' Remember, you'll need to restart the server to reload the environment for this to take effect. # Setting up the controller # We'll go ahead and modify the posts index method to use our new ferret pagination method. app/controllers/posts_controller.rb def index # return everything if no search parameter query = params[:search].blank? ? '*' : params[:search] @posts = Post.paginate_search( query, {:page => (params[:page] or 1), :per_page => 10 } ) # you can also past an additional hash with finder options if needed @posts.member_class = Post # allows hobo index page to work as is end If there is no search parameter supplied, it instead uses * to grab everything. Test this out by adding ?search=searchterm in your address bar. You should see only items that contain matches to your term come back. # Finishing Up # Last step is to add a search field to your index page for easy searching. Looking up the index-page for Post in app/views/taglibs/auto/pages.dryml show this:

Posts

There

Adding our search box after the content-header looks like a decent approach. app/views/posts/index.dryml Search Posts: You can also use the search field from a table plus, however sorting either needs to be dropped or redone because ferret sorts on relevance. # Further Steps # Obviously, the search form could stand to be integrated better style-wise with the rest of the app. So adding some css styles to clean that up would be in order. Ferret has advanced query features, like fuzzy searches, phrase search, field weighting, searching specific fields etc. It might be useful to have a popup with information on advanced search syntax and/or adjust the weights of each field in the index. Also, adding the created_at/updated_at fields might be useful as you can search over time ranges as well. Updating the form or adding an advanced search form that helps build these extended searches could be useful. Check this page for some more information http://www.railsenvy.com/2007/2/19/acts-as-ferret-tutorial (while it refers to an older version, other than the model calls it is mostly correct) or the project wiki which is up to date but a bit harder to follow http://rm.jkraemer.net/wiki/aaf. As you develop your models, remember that ferret keeps the index up to date by using the save/destroy hooks. So, using any ActiveRecord methods which make changes without instantiating the model will cause the index to lose sync with what's in the database. This can make for a very aggravating bug to track down. So avoid ActiveRecord::Base.update and delete in ferret indexed models. Last but probably most important is this... if you're going to have multiple server or even a multi-threaded server hosting your app, you'll want to setup a ferret server. This hosts your index and handles it with transactions to keep your index current.

National characters to ascii letters for user-friendly URLs

2009-06-18T22:35:55Z

Simple way to have nice URLs: 1. use this lib: 2. in your Model add 'to\_param' method that looks something like this: example: def to_param "#{self.id}-#{self.name.to_textual_id}" end I've made few changes to that lib. My version looks like this:

How to switch from the gem to edge as a plugin

2009-04-24T12:42:06Z

If you're currently running the Hobo gem, and wish to run Hobo as a plugin, here are the steps you should follow. If you're using git: git submodule add git://github.com/tablatom/hobo.git vendor/plugins/hobo otherwise: ./script/plugin install git://github.com/tablatom/hobo.git Now edit `config/environment.rb` to remove the `config.gem 'hobo'` line. Edit `Rakefile` to remove the line `require 'hobo/tasks/rails'` if it exists. Before running the next step, I suggest that you check your project in to change control. rake hobo:run_standard_generators You can now enter 'd' on any conflicts to determine whether you have any changes that will be overwritten, and then enter 'y' or 'n' as appropriate. Alternatively, if you checked your project into change control as I suggested, answer 'y' to all of the questions. OK, that's a little extreme -- you can answer 'n' to any of the `application.*` files. Now use your change control system to determine if any of the changes you had previously made have been overwritten. Files with changes that may have been overwritten include `user.rb`, `users_controller.rb` and `environment.rb`.

Generating DRYML from the command line

2009-03-09T18:07:09Z

This recipe is obsolete, there's now a much easier way. See [this hobo-users post](http://groups.google.com/group/hobousers/browse_thread/thread/9501d496add0ad52). After using DRYML for a while, you may want to generate HTML for use outside of rails. Here's how I did it. Note that both of these files live inside a working Hobo skeleton. lib/tasks/render\_test.rake: desc "render test.dryml" task :render_test => ["#{RAILS_ROOT}/app/views/taglibs/test.dryml", :environment] do |t| src = open(t.prerequisites.first).read locals = [] imports = [] renderer_class = Hobo::Dryml.make_renderer_class(src, File.dirname(t.prerequisites.first), locals, imports) assigns = {} view = ActionView::Base.new(ActionController::Base.view_paths, assigns) view.extend(ActionView::Helpers::TagHelper) view.extend(Hobo::HoboHelper) view.extend(Hobo::RapidHelper) renderer = renderer_class.new(File.basename(t.prerequisites.first, ".dryml"), view) page_this = nil page_locals = [] puts renderer.render_page(page_this, page_locals).strip end app/views/taglibs/test.dryml:

Hello!

and then to get the html: rake render_test Note: Most tags work, but the `` tag does not yet -- the functions needed are provided by renderer_class but aren't being found. If you can help, please comment!

Using Single Table Inheritance (STI) models with Hobo

2009-03-01T23:20:15Z

Here's what I needed to do to get STI (Single Table Inheritance) working. It's fairly straightforward, but there are a couple of gotchas. Thus, this recipe. The first gotcha is that you have to have your base table fully generated and migrated before you generate the child model. See [Bug 345](http://hobo.lighthouseapp.com/projects/8324/tickets/345-inheritance-is-broken-again). In my case: script/generate hobo_model_resource DownloadedFile filename:string contents:string script/generate hobo_migrations I chose the "m" option for hobo\_migrations, so the database was migrated. Then once I had the base class working: script/generate hobo_model_resource BatchAcknowledge I then edited *downloaded\_file.rb* and added `sti_type :string` to the `fields` block and added `set\_inheritance\_column :sti_type` below the `fields` block. I then edited *batch\_acknowledge.rb* to change its parent from `ActiveRecord::Base` to `DownloadedFile`. I then removed everything from the file, included the fields definition and the permissions checks -- it gets those from the base class. script/generate hobo_migrations If you want to add additional fields to your sub-models, you have to add them to your base model. This is how ActiveRecord Single Table Inheritance work. However, validations and association definitions may be added to the child model. In my case, I added a field *submission\_id* to the base class, and added: belongs_to :submission validates_existence_of :submission to the child class. Now you should have working inherited models. You'll notice that forms and pages will be generated for *BatchAcknowledge*. Cards are not, but that's fairly irrelevant, because the *DownloadedFile* card will display a *BatchAcknowledge* record, and the auto generator would have generated the two cards identically anyways. In another small gotcha, the name may not propogate correctly for you: see [Bug 387](http://hobo.lighthouseapp.com/projects/8324/tickets/387-inheritance-sti-models-name-not-propagating#ticket-387-1) A larger gotcha is that problems have been reported if you drop the database and try to run hobo_migrations: [Bug 397](http://hobo.lighthouseapp.com/projects/8324-hobo/tickets/397-sti-problems-running-migration-on-dropped-database)

RIA's, "Fit Clients", and hobo?

2009-01-18T20:13:02Z

Hello there. I posted a question awhile ago regarding making Rich Internet Applications (RIA's) with Hobo and AJAX. I was able to get some nice features working with iFRAMEs and a few tricks. But I think this article below speaks to the complexity and hype of AJAX-ified Desktops. http://ruby.sys-con.com/node/510792 Im curious if anyone has looked at Adobe AIR or Flex for RIAs with hobo? Also, has anyone used this framework? http://ruboss.com/framework/ Thanks! Bean

Auto Complete for Agility Project with Hobo 0.8.5 (It works)

2008-12-31T15:29:24Z

First, I'm going by: http://cookbook.hobocentral.net/tutorials/agility (12/31/08). The tutorial on http://hobocentral.net/ needs to be updated. #How to get Auto-Complete to work:# Go down to Section 'A form with auto-completion'. First change "`hobo_completions :username, User.without_joined...`" to "`hobo_completions :name, User.without_joined...`". This change ends up making auto complete bring up results. However, once a user is selected an error pops-up. To fix this, go to '`project_membership.rb`' and add ':accessible => true' to both 'belongs to' variables. That should fix Auto-Complete. #Other Fixes:# In section 'Part 6 – Project Ownership', when you get down to restricting owner for creation permissions. In `def create_permitted?`, `owner == acting_user` should be replaced with `owner_is? acting_user`. Otherwise, no one will be able to create Projects because no one owns a project that hasn't been created yet. In section 'Part 7 – Granting read access to others', right before 'The view layer' the tutorial should tell the user to run migration. I understand that it's not hard to see that you need to migrate before you can view anything, but this is a tutorial and step-by-step instructions are nice. In the next section 'The view layer', there is a slight problem with ``. When memberships were created, Rapid instantly edited the Project page to have memberships and stories listed. That means that it edited the page to have an `` section. The tutorial doesn't take that into consideration and asks the user to modify the entire content. It's good that the user gets a chance to edit this content, but the user will find it weird when they see two side panels in the end. CHANGE this section so that the user just replaces the `` that is already on the rapid page. My code is '`

Project Members

...`'. Thank you, Sean

Deploy a Hobo app on Heroku

2008-11-10T15:23:59Z

This recipe will take you through the process of getting a Hobo app deployed on [Heroku Garden](http://herokugarden.com). We'll work through creating a brand new app and getting it deployed, and then discuss how you would use the same approach with an existing app. **Prerequisites:** you will need git and the herokugarden gem (`gem install herokugarden`) # Deploying a new Hobo app with Heroku Garden **1. Log in to Heroku Garden and create the new app.** Rather annoyingly, Heroku doesn't prompt you for the app name, so we'll start by renaming the app. Click on your email address down in the Heroku bar on the right. That will take you back to "My Apps". Then click "Settings" for the new app, and you'll be able to rename it. Keep the browser open on that page. For the recipe we'll assume you've called it `hoboapp`, but remember that all Heroku apps live in one global namespace, so you'll need to use your own name. Use your name wherever you see `hoboapp`. **2. Grab a local clone of the app**: $ herokugarden clone hoboapp $ cd hoboapp **3. Switch to Rails 2.2.2.** By default a new Heroku Garden app will be configured to use Rails 2.1, but Hobo needs Rails 2.2.2. Edit `config/environment.rb` and change the `` to: RAILS_GEM_VERSION = '2.2.2' (Should be the first line of the file). **4. Add Hobo as a git submodule.** This adds an extra step to making things work with Heroku, but Hobo is a moving target and being able to keep up to date with changes is critical. Having Hobo as a submodule makes this much easier. $ git submodule add git://github.com/tablatom/hobo.git vendor/plugins/hobo When we push our changes, Heroku will not grab the Submodule for us. The easiest way to fix that is to write a simple Rake task that will update any submodules in the app. **5. Create a rake task to do the submodule update.**. Create a file `lib/tasks/git_submodules.rake` containing the following: task :git_submodules do puts `git submodule init 2>&1` puts `git submodule update 2>&1` end **6. "Hoboize" the blank Rails app.** We'll run the standard Hobo generators: ruby script/generate hobo --add-routes ruby script/generate hobo_rapid --import-tags ruby script/generate hobo_user_model user ruby script/generate hobo_user_controller user ruby script/generate hobo_front_controller front --delete-index --add-routes **7. Run the migration generator** to create the initial migration, which will just create the `users` table. ruby script/generate hobo_migration (Chose the 'g' or 'm' option) **8. Commit the code into the repo**: $ git add . $ git commit -am "Hoboize the app" **9. push your code up to Heroku**. Note that you will get an error about the Hobo gem not being available. That's OK. $ git push **10. Run the rake task that we defined above.** The heroku gem allows us to run remote rake tasks: $ herokugarden rake hoboapp git_submodules It may take a while, but you should eventually see the normal output from the `git submodule init` and `git submodule update` commands. **11. Run migrations.** We can use the `herokugarden` remote rake tasks again: herokugarden rake hoboapp db:migrate **12. run Hobo's taglib generators.** Return to your terminal and run: $ herokugarden rake hoboapp hobo:generate_taglibs **13. Install `will_paginate`.** In the file browser on Heroku's edit page, expand the 'vendor' folder and click "Gems and plugins". Select "Available" instead of "Installed" from the menu, and search for `will_paginate`. I found that installing the gem version did not work, so install the plugin version. You should now be able to click the "view" link in the top right of the Heroku editor and see your deployed app up and running. # Deploying an existing app. As far as I know, Heroku want to host the git repo for you, so again we'll need to create a blank Heroku app. Perform steps 1 to 4 exactly as above. Steps 6 and 7 should not be necessary if we already have a running app. We want instead to copy our existing code into this repo, overwriting the files that are already there, but make sure you don't overwrite the `.git` directory. Also, if your app already has Hobo in `vendor/plugins`, don't copy that over, as you've just created a submodule for Hobo. Having copied the files in we want to commit them to git, push them up to Heroku and so on. In other words, perform steps 7 to 13 exactly as above.

Add a footer to every page

2008-11-04T17:06:03Z

Nice easy one here. In application.dryml: ... your custom footer here ... {: .dryml} Note that cusomtising the `` tag like this is common for all sorts of reaons. If you already have an `` in application.dryml, you probably want to just add that footer parameter to it, rather than extending page again (although that is allowed).

Uploading for Hobo app

2008-11-03T13:53:32Z

What if you want to upload a file to your app? You can use the attachment_fu plugin. The model code needs filename and size and perhaps other fields depending on your implementation, surf over to techno-weenie for info on what attachment\_fu supports. This example assumes the model is named ImportProject. fields do content_type :string filename :string size :integer timestamps end has_attachment :storage => :file_system , :max_size => 100.megabytes , :path_prefix => "public/import_projects" validates_as_attachment To get the plugin from the git repository change directory over to the plugins directory clone from git. git clone git://github.com/technoweenie/attachment\_fu.git You may need this patch: create a file appname/lib/attachment\_fu\_patch.rb require 'tempfile' class Tempfile def size if @tmpfile @tmpfile.fsync # added this line @tmpfile.flush @tmpfile.stat.size else 0 end end end And this needs to be added to: appname/config/environment.rb require 'lib/attachment_fu_patch.rb' environment.rb # Be sure to restart your server when you modify this file # Uncomment below to force Rails into production mode when # you don't control web/app server and can't set it the proper way # ENV['RAILS_ENV'] ||= 'production' # Specifies gem version of Rails to use when vendor/rails is not present RAILS_GEM_VERSION = '2.1.0' unless defined? RAILS_GEM_VERSION # Bootstrap the Rails environment, frameworks, and default configuration require File.join(File.dirname(__FILE__), 'boot') require 'lib/attachment_fu_patch.rb' Rails::Initializer.run do |config| ... How about some view code? appname/app/views/import\_project/new.dryml Choose File When you create a new import project you should have an upload button to select the file for uploading.

Dynamically populated {: .dryml} Try adding that to application.dryml and then create a project. The new project wont have a country, so the city menu will be disabled. But if you chose a country, create the project and then go to edit it, you should see the cities from that country in the city menu. We're making progress. # Add the ajax magic We now need to do three things to add the ajax behaviour and tie it all together: - Put the city menu in an ajax 'part' so that it can be updated dynamically - Add some JavaScript to application.js to send to the server (via an ajax call) a change to the country whenever the menu changes - Customize the `new` and `edit` actions in `ProjectsController` so that they can update the project from parameters (i.e. the parameters sent by the ajax call) ## Put the city menu in a part Add a `` to the cusomtised form (`` is just a do nothin tag that can be used to add parts or params without changing the markup) {: .dryml} ## Add the JavaScript We'll use JavaScript to notify the server when the country is changed. Rather than clutter up the page we'll do this 'unobtrusively' by adding a call to `Event.addBehavior` to our application.js: Event.addBehavior({ "form.project select.project-country:change": function(ev) { Hobo.ajaxRequest(window.location.href, ['city-menu'], { params: Form.serializeElements([this]), method: 'get', spinnerNextTo: this, message: ""} ) } }) Let's go through we did there: - Added an `onchange` handler to our select. We used Hobo's default CSS class names to target the right ` <p>Error (add-comment): Object not given - use add-comment object="&blah"</p> </article> <article> <h1>Running a Hobo Application on Heroku</h1> <p>2008-10-20T21:48:55Z</p> This is link to a draft in PDF format. This was done a while ago...needs testing! Describes how to upload and run an app developed on your laptop to Heroku, including mirgrating existing data. </article> <article> <h1>Upgrade an app to the latest version of Hobo</h1> <p>2008-10-17T14:18:53Z</p> ## Breaking Changes It's quite common that there are breaking changes from one version of Hobo to the next. These will settle down once we get to 1.0. In the meantime, there are no general instructions for fixing your app. Have a look at the changelog, any announcements on the blog, or ask in the user group. ## Upgrading Upgrading Hobo is a simple matter of $ gem update hobo Or, if you are tracking edge Hobo using git $ cd vendor/plugins/hobo $ git pull You should also re-run the `hobo_rapid` generator, as some of the assets put in `public` by that generator may well have changed. $ ruby script/generate hobo_rapid For minor upgrades to Hobo that should be enough. Head over to the user group if your app is still not working. </article> <article> <h1>Create a new Hobo app on edge Hobo</h1> <p>2008-10-17T11:32:21Z</p> # Install git First up, you need to have git installed: - [git for windows](http://code.google.com/p/msysgit/) - [git for Mac OS](http://bc.tech.coop/blog/070827.html) - Linux user? I'm sure you don't need any help : ) # Understand the `hobo` command. The main difference when working with edge Hobo is that you don't use the `hobo` command, as this command comes from the version of Hobo you have installed from the gem. Instead you want to manually replicate what this command does for you. There's not much to it -- it just runs a few generators. To make this easier, the `hobo` command actually tells you what it's doing, with lines that start `-->` e.g, if you run the `hobo` command you will see lines like: --> ruby script/generate hobo --add-routes If you run all of these commands (listed below) in a blank Rails app, you will have a Hobo app. The advantage is that you can install edge Hobo first # How to do it ## 1. Create a Rails app $ rails my_app ## 2. Install the Hobo plugin from the github repo $ cd vendor/plugins $ git clone git://github.com/tablatom/hobo.git ## 3. Run the hobo generators ruby script/generate hobo --add-routes ruby script/generate hobo_rapid --import-tags ruby script/generate hobo_user_model user ruby script/generate hobo_user_controller user ruby script/generate hobo_front_controller front --delete-index --add-routes (I ommitted the '$' to indicate the prompt to make those copy-paste friendly) And that's it. For bonus marks, make a script that does all this for you! ## 4. How to get updates $ cd vendor/plugins/hobo $ git pull It's possible that some of Hobo's generated files have changed so you may need to run Hobo's generators again. Most often the only changes are in Hobo Rapid, so run $ ruby script/generate hobo_rapid (don't forget to cd back to the root of the app) </article> <article> <h1>Create an admin subsite</h1> <p>2008-10-16T20:39:18Z</p> A `hobo_subsite` generator has been added to Hobo since this guide was written. The following should still work but is a bit out of date. {: .note} A sub-site is part of a web-app that has the appearance and behavior of a separate site. The most common example of a sub-site is an "admin" section. This guide shows how to create a typical admin sub-site in Hobo. The typical approach to creating a sub-site is to duplicate the required model controllers. So you might have a public facing view of the users at `/users` and the administrators view of the same model at `/admin/users`. These would be managed by two distinct controllers, each with their own set of enabled actions which might not necessarily be the same. For example the admin users controller might have a "new" action at `/admin/users/new`, while the public facing users controller might not enable this action at all if it isn't appropriate. ### Step by Step At the time of writing, Hobo's generators are unable to generate sub-site controllers so it is necessary to create the files manually. Create a new directory `app/controllers/admin/` Create a base controller for the sub-site in `app/controllers/admin/admin_controller.rb`: class Admin::AdminController < ApplicationController hobo_controller # require administrator to access any controller in the sub-site before_filter :admin_required def admin_required redirect_to login_url unless logged_in? && current_user.administrator? end # the default page when visiting the sub-site def index redirect_to '/admin/users' end end {: .ruby} Now create a model controller in the admin sub-site. As an example we will create a controller to manage users. The following goes in `app/controllers/admin/users_controller.rb`: class Admin::UsersController < Admin::AdminController hobo_model_controller User auto_actions :index, :edit, :destroy, :update end {: .ruby} Notice two things that are slightly different to normal: * The controller inherits from `Admin::AdminController` instead of `ApplicationController` * You have to explicitly specify the name of the model as an argument to `hobo\_model\_controller`. In a non-sub-site controller Hobo can usually work this out automatically so it isn't needed. Add a route for the home page of the sub-site in `config/routes.rb`: map.admin 'admin', :controller => 'admin/admin', :action => 'index' {: .ruby} This will enable the route `/admin` which will redirect automatically to `/admin/users` as we set up above. In the base controller we wrote `include_taglib 'admin'`. This means that the tags in `app/views/taglibs/admin.dryml` will be loaded for every action in the sub-site. This is a convenient place to re-define ``, set a theme and define any tags that are specific to the sub-site. As an example, create `app/views/taglibs/admin.dryml` and add the following: Users {: .dryml} Here we've defined an admin specific version of `` that uses an aside layout by default. We've also added admin specific javascript and stylesheet files which you will need to create in `public/javascripts/admin.js` and `public/stylesheets/admin.css`. Finally we have defined our admin specific nav bar containing a link to our users model controller because Hobo excludes users from the nav bar by default. We'll want to tweak Rapid's generic pages to be a bit more admin oriented. By adding the following to `admin.dryml` we can replace the normal list on an index page with an admin style table: {: .dryml} If we add additional model controllers to the admin sub-site they will all use this modified version of ``. Similar admin specific tweaks can be made to the other generic pages and tags. Notice the `fields` attribute on ``. This attribute is given a list of fields that will appear as columns in the table. Our shared definition of `` can't put anything model-specific in there, so we just use "this" which will give a single column with links to each show-page. The good thing is that it's easy to customise this for specific models. For example, say we'd like to add an `email_address` column for the `User` model, just create `app/views/admin/users/index.dryml` like this: {: .dryml} Notice that the call to `` picks up our customised version, since we've overridden it for the entire admin sub-site. </article> <article> <h1>Fall back to Rails techniques in your views</h1> <p>2008-10-16T20:38:27Z</p> # How To: Fall back to Rails-style views. Audience: Anyone that knows Rails-style views (ERB + Rails helpers) and is starting to learn DRYML and Rapid. While learning to write your views using DRYML and Rapid, you might find yourself stuck trying to do something that you'd be perfectly capable of using ERB and Rails helpers. Obviously the ideal solution would be to learn the "Hobo way", but given that documentation is still a work-in-progress, you might need to just "do it the old way". We'll start with the most extreme example of "doing it the old way" and work forward to more preferable options. ## Fall back completely to an ERB template. Rails supports multiple template languages, and uses the file suffix to pick the right one. So simply by calling a template, say, `index.html.erb` instead of `index.dryml`, you have created a normal Rails template. Templates like this will co-exist with any DRYML pages without a problem. The main downside to doing this is that Rails apps typically use a 'layout' to provide parts of the page that are common to all pages, while DRYML pages typically use a `` tag. Your `.html.erb` file won't get the same page structure that the DRYML pages get. You could always create a Rails layout, but that's not a great idea as you'll have to manually keep it in sync with your DRYML `` tag. There is a better way... ## Using the `` tag + ERB You can solve the problem of the missing layout by sticking with the `.dryml` suffix (i.e. the page is a DRYML page), but still mark-up the entire page in ERB. You just have to wrap your ERB in the appropriate parameter of the `` tag. e.g. By convention, the DRYML `` tag will normally provide two parameters (among many others) that will suit this purpose. If you just want to get the `` section from the page tag -- things like JavaScript includes and CSS stylesheets -- and you want to provide the entire HTML body yourself, then use the `` parameter (remember, every DRYML tag that ends with a ':' is a parameter to the encolsing tag -- `` in this case): ... write a regular Rails-style ERB template here ... {: .dryml} You will probably want more than just the `` section though. You will want the "theme" of the site -- the page header, site title, nav bar etc. In this case, use the `` parameter ... write a regular Rails-style ERB template here ... {: .dryml} It's important to understand that if your application defines a custom `` tag, the `` and `` parameters might not exist. These are just conventions. All of Hobo's built-in pages do provide those parameters though, so if you are working from a typical Hobo app, the above examples will work as advertised. ## Using small fragments of ERB and helpers Hopefully your pages will be entirely written using DRYML and Rapid. If you find that there's just one small part you can't figure out, say a link, or a form, you can just drop down to ERB and helpers for that one thing. Here are a couple of examples. ### Links Say you wanted to add a link to the current user's "My Account" page, which is at `/users/123/account`. Because Hobo uses normal Rails conventions of RESTful routing, you can use the familiar `link_to` helper. Here's how you would add that after the heading on one of Rapid's generated `show` pages: "users", :action => "account", :id => current_user %> {: .dryml} ### Forms Again, because Hobo doesn't change any Rails conventions for routes or for form parameter names, if you really can't figure out how to get a DRYML/Rapid form working, you can always fall back on a "normal" Rails form. As an example, we'll completely replace the form on one of Rapid's generated 'edit' pages, say for a 'person' model. The generated `` tag exposes the `` tag as a parameter, so we can replace it with ``: Name : <br /> Biography : <br /> {: .dryml} </article> <article> <h1>Add your own rich type</h1> <p>2008-10-16T19:46:14Z</p> Say your application features currency value, and you'd like them all formatted nicely. A great way to implement this in Hobo is by creating a new type, e.g. `Dollars` and customising the way those values are displayed. That way your dollar values will be displayed correctly throughout the site and you won't need to think about that issue again. ## Start with a blank app To make this how-to very concrete let's start from scratch with a new application: $ hobo my_app $ cd my_app $ ./script/generate hobo_model_resource product name:string ## Create the type Now we'll dive right in and create the new type. Create `app/models/dollars.rb` like this: class Dollars < DelegateClass(BigDecimal) COLUMN_TYPE = :decimal end {: .ruby} Let's talk that through. It's common with Rich types to create a new subclass of the 'normal' type that ActiveRecord would use. For example, Hobo's `HtmlString` is a subclass of `String`. Unfortunately, subclassing `BigDecimal` is problematic for reasons we won't bother going in to. Fortunately Ruby saves us with the very nifty `DelegateClass`. This allows us to walk like a `BigDecimal` and talk like a `BigDecimal`, which is perfectly good enough in Ruby. We then declare COLUMN_TYPE = :decimal {: .ruby} which tells the migration generator what type of column to generate for these things. That's arguably redundant seeing as we already defined these things as being a special kind of `BigDecimal`. This step might go away in the future. ## View layer To render these dollar values nicely in the app, we need to define a custom `` tag. So in application.dryml we need: $ {: .dryml} ## Declare a field with the custom type Now our type is ready to go. We can edit `app/modes/product.rb` like this: class Product < ActiveRecord::Base hobo_model fields do name :string price Dollars, :precision => 12, :scale => 2 timestamps end ... end {: .ruby} Notice the type of the `price` column is given as the class constant `Dollars`. We can pass the same options that we could to a regular `:decimal` column # Create the database If we now run the migration geneartor: $ ./script/generate hobo_migration You'll see that the price column is `:decimal` type (the users table has been omitted for brevity): ---------- Up Migration ---------- create_table :products do |t| t.string :name t.decimal :price, :scale => 2, :precision => 12 t.datetime :created_at t.datetime :updated_at end ---------------------------------- ---------- Down Migration -------- drop_table :products ---------------------------------- {: .ruby} ## Try it out That's it! You can now fire up the app and sign up to become the administrator. Create a product with a price, and see the nice dollar formatting. ## Bonus - a custom input for dollars Add this to `app/views/taglibs/application.dryml` $ {: .dryml} You'll now have a dollar sign in front of every dollar field in your forms. </article> </main></body></html>