Opinions sought on best way to implement "filter" PLUS "search" pattern
rovnak
Any recommendation on the best way to implement the following pattern.
I have a list.
I want to allow users to "filter" the list based on the values of some
of the more important fields (like for example "city". ).
I want this filter to then remain in effect while the user does all
the other standard operations that you would expect from the
ActiveScaffold list - i.e. column sorting, pagination, and applying
additional "search" criteria. (i.e. applying say a telephone number
search via the standard search field).
So my question is whether I should try to implement the above
functionality by having my "filter" piggyback on the conventional
search infrastructure (i.e. implicitly appending the "city" value to
the conventional AS search infrastructure) OR applying the "filter"
logic in a separate fashion, independent of the AS search
infrastructure.
Do you follow the scenario? Any opinions?
souvey
searches just append your additional qualifiers
I'm not sure how else you would apply it without breaking other
features, although I'm not positive about that
Just my input...
Lance Ivy
I'd probably piggyback on the search infrastructure and when the user
searches just append your additional qualifiers
I'm not sure how else you would apply it without breaking other
features, although I'm not positive about that
Just my input...
On Apr 7, 1:49 pm, "rovnak" <donloga...@gmail.com> wrote:
> Any recommendation on the best way to implement the following pattern.
>
> I have a list.
>
> I want to allow users to "filter" the list based on the values of some
> of the more important fields (like for example "city". ).
>
> I want this filter to then remain in effect while the user does all
> the other standard operations that you would expect from the
> ActiveScaffold list - i.e. column sorting, pagination, and applying
> additional "search" criteria. (i.e. applying say a telephone number
> search via the standard search field).
>
> So my question is whether I should try to implement the above
> functionality by having my "filter" piggyback on the conventional
> search infrastructure ( i.e. implicitly appending the "city" value to
rovnak
submit side. That is not my problem. My problem is persisting the
extra conditions into the generated list page so that they continue to
be submitted with each column sort and pagination.
On Apr 9, 8:29 pm, "Lance Ivy" <l...@cainlevy.net> wrote:
> Or you could use the conditions_for_collection method, designed to let you
> merge your own search conditions into the infrastructure. Seehttp://activescaffold.com/docs/api-list.
>
> On 4/7/07, souvey <sou...@gmail.com> wrote:
>
>
>
> > I'd probably piggyback on the search infrastructure and when the user
> > searches just append your additional qualifiers
> > I'm not sure how else you would apply it without breaking other
> > features, although I'm not positive about that
> > Just my input...
>
> > On Apr 7, 1:49 pm, "rovnak" <donloga...@gmail.com> wrote:
> > > Any recommendation on the best way to implement the following pattern.
>
> > > I have a list.
>
> > > I want to allow users to "filter" the list based on the values of some
> > > of the more important fields (like for example "city". ).
>
> > > I want this filter to then remain in effect while the user does all
> > > the other standard operations that you would expect from the
> > > ActiveScaffold list - i.e. column sorting, pagination, and applying
> > > additional "search" criteria. (i.e. applying say a telephone number
> > > search via the standard search field).
>
> > > So my question is whether I should try to implement the above
> > > functionality by having my "filter" piggyback on the conventional
> > > search infrastructure (i.e. implicitly appending the "city" value to
Lance Ivy
1) use the session
2) use a parameter name that is not in our parameter blacklist (all urls use the params_for method, which merges with the current parameters and blacklists a few. see lib/helpers/active_scaffold_helpers.rb)
> > > search infrastructure ( i.e. implicitly appending the "city" value to
rovnak
On Apr 9, 11:35 pm, "Lance Ivy" <l...@cainlevy.net> wrote:
> Oh, I see! Usually I recommend one of two methods:
>
> 1) use the session
I don't like the idea of using session since users will often open
more than 1 browser or tab, particularly when searching through lists
of data - which is what the scaffold list is good for. If you rely on
sesson storage you can completely screw up the experience. I hope that
ActiveS is NOT relying on session storage of search, pagination
criteria since this is generally a disastrous strategy in browser
based app.
The application framework that I first developed web applications
with, nearly 10 years ago, had a feature called "page_session" which
was affectively an encoded hash of values that were persisted to a
given page rendering as a special hidden field, or query string
param. This was extremely useful for storing the type of thing I am
talking about. Page session had a developer API that was just like
server side session, however, it was better for the storage of things
which needed to be bound to a particular page rendering - for which
server side storage was innappropriate and downright dangerous.
> 2) use a parameter name that is not in our parameter blacklist (all urls use
> the params_for method, which merges with the current parameters and
> blacklists a few. see lib/helpers/active_scaffold_helpers.rb)
Ok, this sound good , I still need to figure out the lifecycle of
where to call this from. I am looking into it.
> > > > > search infrastructure (i.e. implicitly appending the "city" value to
Mike Perham
On 4/9/07, rovnak <donlo...@gmail.com> wrote:
>