derekcroft / zable

HTML table generation with searching and sorting made dead simple

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Simpler way to create search forms

joekur opened this issue · comments

So to make a search form right now I might have something like that.

= form_tag current_url, method: :get do
  = text_field_tag 'search[name_or_email]', (params[:search] && params[:search][:name_or_email])
  = submit_tag "Search"

I should be able to preserve my sort params and my page size params. To do that I also have to add some hidden fields:

= hidden_field_tag 'sort[attr]', params[:sort][:attr] if params[:sort] && params[:sort][:attr]
= hidden_field_tag 'sort[order]', params[:sort][:order] if params[:sort] && params[:sort][:order]
= hidden_field_tag 'page[size]', params[:page][:size] if params[:page] && params[:page][:size]

I think this a bit too much overhead for our gem users. Namely the way you have to grab the current search values and especially the hidden fields. But we want to keep it very flexible, so maybe if we just had a couple helpers?

search_param("name_or_email")
zable_hidden_search_fields()

What do you think?

This is where the extra_params comes in. If you make these hidden fields, then you'll have to POST the form to search, sort, or page, which is not what you want. Instead, you want to embed all of the extra params in each link the gem creates.

How would the extra_params help to persist sort/page_size state? The search form I had as an example isn't produced by zable, it's just hooking onto the search params - isn't that the only way to do search?

Is that true it must use POST? It seems to be working fine for me as is with GET.

Actually, yes, that makes perfect sense. I was thinking about the links on
the column headers, which is totally different from what you're asking
about. :)

Cool. I implemented the hidden field helper, but figured the other thing was kind of unnecessary.