What’s new in ARON 2.0

ARON 2.0 is the second generation of the portal. It keeps the data model, the configuration files and the public URLs of the old portal, and replaces the rest: the reader interface, the search layer, the API and the way the portal is built and deployed. This page summarizes what a deployment gets and where in this guide each part is described. A deployment of the old portal finds the steps it has to take in Coming from the old portal.

One application, one artifact

The backend and the web interface are one executable jar, released inside a bundle together with a complete default configuration for a Czech archive and an installation readme. The same jar serves the portal at the root of a URL and under a subpath, chosen by configuration or by the reverse proxy, without a rebuild. There is no separately deployed frontend and no static configuration file served next to it.

The internal SOAP interfaces for Transfagent live under /cxf/*, outside the public /api namespace, and can be moved to a listener of their own (soap.port) so that the public port never answers them. See Installation.

A new reader interface

The web interface is rewritten. It is responsive — the search page stacks its sidebar and the header folds its section tabs on a narrow screen — and built to be accessible (keyboard operation, ARIA labeling, WCAG 2.1 AA as the target), because the public-sector bodies that deploy the portal are legally required to publish an accessible site. What the reader sees:

  • A configurable home page: the search box plus groups of tiles that lead into a section’s search or to an external page, and a footer band of prose and links, all typed configuration in pageTemplate.yaml. No raw HTML is configured anywhere.

  • A record page with the archival description as a resizable tree pane, the record’s description beside it and, when the record has digitized material, the scan shown immediately in an embedded deep-zoom viewer; further pages and files stay one click away. The viewer also has a page of its own for deep links and the browser’s full-screen mode.

  • Search with a dual-thumb dating slider, checkbox facets with optional explanations, an advanced search dialog that offers a section’s whole facet list as a draft and counts the results before it is applied, and find related, which lists every record that references the one on screen.

  • Citations of a record in the form the deployment’s archivists agreed on, copied verbatim to the clipboard.

  • Czech and English interfaces. The reader’s language is remembered; a deployment sets the default and which languages are offered.

See Configuration for the page template, the home page, the citation forms and the structured search results.

Data ingest and the search index

The search index is written after an import has committed, from the database. A failed import therefore changes nothing in the index, and a renamed fund renames itself in every description’s card and reference facet without those descriptions being re-delivered. Records to re-index can be requested with one SQL statement; a full rebuild happens by itself whenever the indexed-fields configuration changes.

Besides the SOAP file transfer from Transfagent, transfer folders in a configured input directory are imported at startup, with a journal that skips unchanged folders. Transfagent withdraws published data through a management SOAP interface that shares the import’s lock, so a deletion can never interleave with an import. See Operations.

A new API, and the old one kept

The portal has a new REST API under /api/v1, defined in a TypeSpec contract whose OpenAPI description is published with the sources. It is the API the new interface uses and the one third parties should build on. The old API under /api/aron is preserved verbatim, including the permalink redirects, so existing links and clients keep working; it is frozen and receives fixes only.

Configuration

The configuration files of the old portal keep their names and their content: application.yml, the display model types.yaml, the facets searchConfig.yaml, pageTemplate.yaml. What is new:

  • Translations live in sibling files: types_localization.yaml, searchConfig_localization.yaml and the like translate the configured labels without editing the configured file. The reader’s language is a request parameter of the API, so responses stay cacheable.

  • Datings are rendered by the server in the reader’s language, with the archival grammar of estimates, centuries and intervals.

  • Structured search results (record cards prepared by the source system) are shown whenever the record carries one; their presentation is configured in resultLayout.yaml.

  • Citation forms are configured in citation.yaml, several per deployment, each with the record types it covers and its own script.

  • Mistakes fail the startup: an unknown key, a facet condition the portal cannot read, a home-page tile that leads to a search the portal would reject, an image that cannot be served. The error names the file and the value, so a configuration mistake is found by the administrator, not by a reader.

  • Disclosure is opt-in: the running version and the diagnostic reason of a failed request are sent only where a deployment turns them on.

See Configuration.