1

A core piece of the application I'm working on is allowing the user to explore a complex dataset by progressively add search terms. For example, you might start with a free-text search, then progressively add (or remove) some facetted search terms, move a slider to constrain some dimension of the returned results, etc.

Conceptually, it seems to me that the user is incrementally defining a set of constraints. These constraints are used to search the dataset, and the rendering of the results provides the UI affordances to add further search refinements. So building this in Rails, I'm thinking of having one of the models be the current set of search constraints, and controller actions add to or remove constraint terms from this model.

Assuming this is a sensible approach (which is part of my question!), I'm not sure how to approach this in Rails, since the search is an ephemeral, not persistent, object. I could keep the constraints model in the session store, but it seems rather a complex object to be marshalled into a cookie. On the other hand, I could put store the constraints model in a database, but then I'll have a GC problem as the database fills up with constraint models from previous sessions.

So: how best to build up a complex interaction state in Rails?

Ian Dickinson
  • 12,875
  • 11
  • 40
  • 67

2 Answers2

1

I had to solve this problem for several apps so I wrote a small gem with a DSL to describe these searches:

https://github.com/fortytools/forty_facets

Axel Tetzlaff
  • 1,355
  • 8
  • 11
1

Here's some pointers

  • create a class XxxSearch with accessors for all the search facets: keywords, category, tags, whatever. This class should be ActiveModel compatible, and it's instances are going to be used in conjunction with form_for @xxx_search. This class is not meant for persistence only for temporaryly holding search params and any associated logic. It may even act as a presenter for data: @xxx_search.results, or implement search data validations for each faceting step.
  • incrementaly resubmit the form via wizard technique, or even ad-hoc data insertion on a large form.
  • allways submit the search via GET, as such:
    • the search is bookmarkable
    • you can chain the params to pagination links easily like: params_for(params[:search].merge(:page => 3))
    • you need NOT use the session, the data is forwarded via GET params, as such:
      • can keep using cookie session store
      • escapes you from a lot of headaches when the last search is persisted and the user expects a new search context (I say this from experience)
Community
  • 1
  • 1
clyfe
  • 23,695
  • 8
  • 85
  • 109
  • Thanks clyfe. I agree that creating action URL's with the complete search state embedded as params would have some advantages. The wizard plugins seem to enforce a certain sequence of form data submissions, rather than allow the user to randomly volunteer any available constraint. Could be useful on other parts of the project though. – Ian Dickinson Jan 04 '12 at 14:15