Now, I’m expecting to stick a Hash into ‘filters’ in the form:

So, the idea is, the object that is saved with the above filters Hash provides a context for searching through another collection of objects (let’s call it OtherThings) using the filters. (think email rules in Outlook). Anyway, don’t worry too much about that. It’ll become more clear once I launch BigAuthor in a few weeks or so.

Using InheritedResources + Formtastic gives you a big advantage in creating resourceful controllers and their associated semantic forms really, really quickly.

The controller:

Seriously. It’s that empty.

The ‘new’ form page (in HAML, of course):

Again, that’s it. Really. The checkboxes that are checked get put into Arrays within a params['thing']['filters'] Hash and persist naturally to MongoDB through MongoMapper. No extra work needed.

In fact, the only extra thing I did was to write a short override into the create/update methods so that it strips the blanks from the internal filter arrays. (formtastic’s checkboxes post an empty string for every checkbox that is not checked, which in this case wasn’t what I wanted, but it might be fine or even required for your purposes)

BONUS!

Using Sunspot and Solr for your search solution in your MongoMapper app? Here’s a sample of the search method that my OtherThing class has for creating a search result set based on the filters:

Exactly how my Sunspot/Solr is setup, I’ll leave for the reader to imagine, but don’t overthink it… it’s not complicated and the above works fast… really, really fast. So fast, that instead of pre-creating and caching the results sets, I just re-generate them on the fly, thereby ensuring they’re always up-to-the-second with the latest OtherThings that have been added to the database.

Once again, Mongo and MongoMapper blows me away with its simplicity, further supported by the brilliant inherited_resources and formtastic!

Take it for what it is: a point of discussion.

Of course, the skeleton of any Rails app will vary from project to project, depending on needs.  Agile approach is to only add it to your framework if you actually need it right now, though some stuff tends to be easier to use (like authentication systems and databases) if you build it in up-front.  That tends to be my approach for green-fielding Rails apps.

If you’ve got some favorites that you use, feel free to post in the comments about it! I’m always interested in hearing about new stuff that makes my life easier/more fun.

FOR MY ACTIVERECORD-BASED APPS

• inherited_resources
  • for building clean, simple resource-oriented controllers.  the Rails 3.0 guys recommend you start using this with Rails 2.3.5 apps because Rails 3.0′s new controller syntax is basically derived from inherited_resources (and jose valim is on the rails core team now)
• authlogic
  • the reigning champ (in my opinion) for a while in terms of a really simple, basic user authentication solution.  i’ve also tried clearance, lockdown, ye olde restful_authentication, and others.  I still like authlogic alot, but the new Devise system seems to be really solid and might be good enough to get me to switch for new apps
• searchlogic
  • really handy extra methods for activerecord queries
• haml / sass
  • blah blah blah http://blog.digimonkey.com/2010/02/why-use-haml-and-sass-i-already-know-html/
• formtastic — http://github.com/justinfrench/formtastic
  • if you intend to produce semantically-correct, standards-compliant xhtml, your biggest enemy is trying to get forms to both look right and be semantic xhtml.  formtastic takes you a long way towards that goal, while also cleaning up your views significantly. and if you need to do something weird for a form that doesn’t quite work with formtastic, it doesn’t get in your way.
• compass + blueprint
  • blueprint is just a CSS framework for laying out 950px wide fixed layouts in a clean way; particularly great for multi-column layouts, which can be notoriously tricky to get right and cross-browser
  • compass adds a layer on top of blueprint + Sass to make html/css design really easy and slick; saves you a TON of time and makes it easier to get the cross-browser stuff working (or 99% working) on the first try, instead of spending a whole day fighting IE 7
• hoptoad
  • exception notification to a third-party service that integrates with lighthouse, github, et al
• acts_as_state_machine
  • self-explanatory
• acts_as_taggable_on_steroids
• acts_as_rateable_with_weights (mine) – http://github.com/mepatterson/acts_as_rateable_with_weights
  • forked my own version of acts_as_rateable to add weighted ratings and bayesian averages
• will_paginate
  • makes it much easier to handle pagination on any enumerable object collection (ActiveRecord objects or not)
• ssl_requirement
  • allows you to lock down controller methods so they won’t work unless the requestor is hitting them through SSL
• statistics – http://github.com/acatighera/statistics
  • have used this exactly once.  liked it, but didn’t use a ton of its features.  seems pretty robust though.
• jrails plugin (+ nuke the prototype stuff and replace with jquery)
  • self-explanatory; prototype is dead. long live jquery.
• xapian or thinking_sphinx
  • i’ve gone through so many different search engines for so many projects.  I think I’m the only one using Xapian.  It actually works pretty well, but is lacking in a lot of ways.  Thinking sphinx is similar; easier Rails integration, but missing some stuff, though it’s highlighting and excerpting work nicely.
• paperclip
  • super-simple file attachments on ActiveRecord models
• carmen — http://github.com/jim/carmen
  • “helpful collection of geographic names and abbreviations for Rails apps (includes replacements for country_select and state_select)”
• stringex — http://github.com/rsl/stringex
  • helpful assortment of extra string methods
• admin-data — http://github.com/neerajdotname/admin_data
  • every app ends up needing some sort of admin backend to rifle through the data layer, at the very least in development mode; pretty useful
• bullet — http://github.com/flyerhzm/bullet
  • stupid-simple plugin that helps you find N+1 queries and other query performance problems
• factory_girl, shoulda, faker
  • i liked factory_girl a lot until my company started using machinist, so now I think I like that better.  shoulda is great.  faker is indispensable, imho.
• db-populate – http://github.com/ffmike/db-populate
  • i’ve been using this in my older AR-backed apps.  probably won’t need it in 2.3.5 or 3.0 apps, though i do like how ffmike did db-populate.  i think it might still be more robust than the db:seed thing built-in to Rails

FOR MY MONGO_MAPPER APPS

• mongo
  • [GEM] the base MongoDB ruby driver
• mongo_ext
  • [GEM] C-extensions for the above to make it perform better
• mongo_mapper
  • [GEM] John Nunemaker’s thin ORM layer for Mongo.  fairly young and poorly documented, but it’s such a thin wrapper that it hasn’t been a problem for me.  just gives you some basic ActiveRecord-ish relationships and conveniences for using Mongo Documents and EmbeddedDocuments with standard Ruby models.
  • http://railstips.org/blog/archives/2009/06/27/mongomapper-the-rad-mongo-wrapper/
  • http://railstips.org/blog/archives/2009/12/18/why-i-think-mongo-is-to-databases-what-rails-was-to-frameworks/
  • http://rdoc.info/projects/jnunemaker/mongomapper
• sunspot[GEM] + sunspot_rails[GEM] (with custom config for mongo support) – http://github.com/outoftime/sunspot
  • found that sunspot integrates the solr search engine more easily with mongo than anything else out there.  has a lot of nice features, and it does automatic indexing on the fly, rather than requiring some sort of nasty cron job or handrolled delta-indexing solution
• handrolled auth system derived in part from authlogic
  • so, i probably should start using Devise, since it apparently has native mongo_mapper support.  but for the two mongo apps I’ve built thus far, i just handrolled a simple authentication system by adapting the core code from authlogic and removing all the ActiveRecord-specific bits.  works fine, easy to add on custom stuff.  but Devise is probably better for the future.
• machinist, shoulda, faker
  • see above
• acts_as_mongo_rateable (mine) — http://github.com/mepatterson/acts_as_mongo_rateable
  • I wrote this from scratch, inspired by the basic architecture of the acts_as_rateable plugin for ActiveRecord
• acts_as_mongo_taggable (mine) – http://github.com/mepatterson/acts_as_mongo_taggable
  • I wrote this from scratch, inspired by the basic architecture of the acts_as_taggable_on_steroids plugin for ActiveRecord
• will_paginate
  • works fine with any enumerable object, so works with Mongo
• compass + blueprint
  • see above
• haml / sass
  • see above
• jrails plugin (+ jquery instead of prototype)
  • see above
• inherited_resources
  • this works largely the same with Mongo, since your resource-based controller shouldn’t really have any direct dependence on your database ORM
• hoptoad
  • see above

STUFF I’D LIKE TO USE/WANT TO INVESTIGATE FURTHER

• devise – http://github.com/plataformatec/devise
  • has mongo support baked in!  looks really cool and has a lot of robust functionality.
  • example using with mongomapper – http://github.com/theshortcut/devise_mongomapper_example
• easy ESI — http://github.com/grosser/easy_esi
  • haven’t looked at it much; seems like an interesting approach
• aegis – http://github.com/makandra/aegis
  • seems like a really nice way to do complicated roles and permissions.  haven’t used it though.  dunno if it will work with any of the good auth systems like devise, clearance, authlogic, etc.  in most cases, might just be easier to write your own simple roles system (which is what i’ve done in ALL cases)

Given: a Users collection where the users’ names are stored in an Array key called name. i.e. :name => ["Patterson", "Matt"]. It can be any length, so if they want middle names or titles or whatever, it just gets stuck in there as an element on the array.

Problem: Need to create a really quick lookup to do autocomplete when someone is looking for a particular person in the database.

Solution:

So when the user types “m” into the autocomplete field, it will quickly populate the suggestions with ["Patterson", "Matt"] and ["Magdalene", "Mary"] and ["Munchausen", "Baron"] and ["Mr.", "John", "Arbuckle"]. But it won’t pickup people with ‘m’ in the middle of any of their name components, like ["Hammer", "Captain"].

How simple is that?

UPDATE: 11 Apr 2010
As it turns out, you can make the above even faster:

without the ‘.*’ bit, apparently mongo’s regex implementation gets a huge speed boost since it’s not having to parse the rest of the string once it hits a match.