Loading

Overview of Browse Views

A browse view is a public, searchable catalogue of one datastore's records, such as courses, venues, vacancies or products. Visitors filter, sort, search and page through it without signing in, and each record is drawn as a card from an HTML template you write.

Where to find it

Architect Panel → Layout & Pages:

  • Browse Views — the list of views; open one in the Browse View Builder to configure it

What a browse view is, and is not

  • Public. No sign-in is needed, and the listing is deliberately not limited by organisation: it shows the datastore's records to anyone. Use the Filter Data card to restrict what is published.
  • One datastore. Each view lists records from a single datastore, shown in the Builder as the Database Table Name.
  • Cards, not columns. Each record is drawn from the List template under Item Appearances; there are no columns to size or headings to click.
  • Not an admin grid. For lists staff work with, use the datastore's own list in the administration screens.

Visitors open a browse view by its number (its ID in the Browse Views list), so link to it from your site's menus or pages.

The Browse View Builder

The Builder shows the view's name and datastore at the top, then these cards:

  • Field Configuration: for each field, its Filter Mode, whether it is included in search, whether it is sortable, and whether it is shown at all. See Configuring Columns.
  • Paging: Records Per Page, from 1 to 100 (100 by default).
  • Item Appearances: the List, Search and Map Pin templates, with a Placeholder Tags panel.
  • Filter Data: standing conditions every listing obeys, such as "Published is Yes".
  • Location & Distance: nearest-first sorting, a radius filter and a map. See Sorting by Distance.

Click Save Browse Layout to save. Problems are reported in a pop-up titled "Error".

Building a view

  1. Create the view in the Browse Views list, choosing its datastore, then open it in the Builder.
  2. In Field Configuration, tick Show in Browse View for every field the cards use, and choose which fields filter, search and sort.
  3. Write the List template, using tags such as ##AMDATA_title##; ##AMDATA_ID## is always available for building a link to the record.
  4. Add a Filter Data condition so only records meant for the public appear.
  5. Set Records Per Page, save, and open the view as a visitor would.

Paging

Results are served a page at a time. Visitors see "Results:" with the total number of items across all pages, and a pager with page numbers, first and last links, and "Page X of Y". The pager is hidden when everything fits on one page. Changing a filter, the sort, the postcode or the distance returns to page 1.

What goes wrong and how to tell

  • A card shows a raw tag such as ##AMDATA_price##: that field is not ticked Show in Browse View. In the Placeholder Tags panel, green tags are available and red ones are not.
  • "Unable to find view ID": the view number is wrong or belongs to another organisation.
  • "Results: 0 Item(s)" and nothing else: the Filter Data conditions or the visitor's filters exclude everything. There is no empty-results message, so consider saying in the page text what to try.
  • The listing stops loading after a Filter Data change: a condition could not be applied. Simplify it.

Worked example

A college publishes its short courses. The view lists the Courses datastore, filtered by Filter Data to courses marked Published. Subject is a Tickbox List filter, Fee (a number field) a Range Slider, and Title is both searchable and sortable. The List template shows the title, dates and fee with a "Book" link built from ##AMDATA_ID##, and Records Per Page is 24, so the 130 courses span six pages.

Recommendations

  • Always set Filter Data, because the view is public.
  • Tick Show in Browse View only for fields the cards need; nothing else leaves the server.
  • Link each card to the record with ##AMDATA_ID##; there is no automatic click-through.
  • Keep pages to a size people can scan, typically 20 to 50.