Page MenuHomePhabricator

Separate frontend and backend code in the Pager hierarchy
Open, Needs TriagePublic

Description

The Pager hierarchy contains code to deal with both the retrieval of results from the backend (doQuery, getQueryInfo, etc.), and the formatting of these results (formatRow, getNavigationBuilder, etc.). The hierarchy itself is built upon this confusion:

  • IndexPager
    • AlphabeticPager: changes the backend (basic implementation)
    • ReverseChronologicalPager: changes the backend (ordering), but also the frontend (adds header row and row groups)
    • TablePager: primarily changes the frontend (turns it into a table), also slight changes to the backend (adds sortability)

It would be nice to disentangle these two aspects into separate classes: for example, leave only the backend logic in Pager / IndexPager, and introduce a separate PaginationFormatter hierarchy that deals only with the frontend aspects. This would reduce the complexity of the whole hierarchy, and make it easier to reuse logic, also giving more flexibility to the developer, by not constraining them to a specific backend + frontend preset.

Event Timeline

Ideally it should be separated into model logic (fetch a set of DB rows with paging, sorting etc), presentation logic (render a HTML list or table) and controller logic (e.g. some pagers do PII access logging).

As a quick and dirty improvement, it would be nice to have a way to use the existing Pager objects to get a resultset rather than formatted HTML. (IndexPager::reallyDoQuery() does that, but it's unclear if it's safe to use directly.)