FFRIndexed::Template - Render and interactively refine a FFRIndexed query (name to change)
A likely good name would maybe be FFRIndexed::View or something like that, as it's a class conveniently usable from any templating system that has method calls on objects.
Creates a new view. The following parameters are optional but allowed:
The FFRIndexed file index to use. If none is given, one will be instantiated.
The query (as data structure) to use.
The default category to use.
The columns to display.
The order in which the columns are displayed.
An instance of Table::Denormalized::ColumnRefiner
List of the parameters which persist over queries. This is used to append/discard CGI parameters from the query string. If none is given, a new instance of CGI::PersistentParams is created with the following columns to discard:
action _id super_search Search column template ss _
The number of items per page. Default is 20.
The page to display. Default is 0.
The pager object to use. Default is a new instance of Data::Page
The HTML::Prototype object to use. Default is a new instance.
Returns a link to the current query, modified by
$ARGREF, suitable for use from within Template Toolkit. Very convenient if you want to page through a sorted set. All CGI query parameters are preserved. If you want to erase a parameter, pass <tt>undef</tt> in the argument.
Returns a list of hidden parameters of the current query from
persistent_params, as modified by
$ARGREF. Convenient for inclusion in a form.
Returns the list of available plugins of the given type. The type can be one of
page ... ...
Returns the list of refinements for the current query.
Returns the list of the columns that were not explicitly named in the query, but still add no subdivision to the results.
Returns the names of the columns mentioned explicitly in the query. This needs to be set in the constructor, otherwise some dodgy and untested logic will be used that will likely mistreat SuperSearches, as these potentially mention many columns.
Returns the refinement for the column
Returns the refining columns for the current query.
Returns all columns
Returns all non-trivial columns from the set of given columns. Using this should somehow differentiate from user-requested columns and determined columns. Some day.
Maybe "refining columns" should take a list of admissible columns. The the two functions could be merged into one function.
$view->resultset START, COUNT
Initializes and retrieves the full resultset from the database. It returns the resultset as an array reference. This is currently overkill as only the overall size of the resultset and the items on the "current page" are actually needed.
This method will later return only the count and the "relevant" rows and not retrieve everything from the database.
Or maybe not, as the Playlist plugin relies on the fact that all rows are available.
$view->resultset_list START, COUNT
resultset, except that it returns a list instead of an array reference.
Returns the next
COUNT items after
START. This is convenient to implement the concept of a "current page", for example using Data::Pager.
Returns a Data::Page object for convenient paging through the resultset.
$view->keyword_complete KEYWORD COLUMNS
Returns a (unique) list of matching keywords from the
The matching is done via case insensitive substring matching.
This should likely go somewhere else separate instead of being part of this module.