Orbeon Forms store all forms data in a unique table and then create views
called "flat views", with one column for each form field.
This application connects to the Orbeon database and fetch relevant form data
from the flat view. A read-only access (SELECT privilege) is enough.
Form name, URL, fields, view name are all provided in configuration
The classes ApplicationConfiguration and Form both map the config properties.
[ Contents ]
The application controller serves 3 routes:
- app index, with a list of forms
- form index, with a list of entries
- form details, with entry fields and link to Orbeon
When only one form is configured, the app index redirects directly
to that form.
[ Obsidian applications as separate libraries ]
This introduces a new pattern: instead of committing application code
directly into Obsidian Workspaces, the application is a stand-alone
library.
Applications are expected to put their classes:
- in Waystone\Apps\<unique name> namespace when maintained in apps/
- in any other namespace when maintained outside Obsidian repository
In the future, applications will be able to define waystone/framework
as dependency to get access Obsidian Workspaces classes. Meanwhile,
PSR-4 namespaces resolution is done at root composer.json level.
[ Configuration and environment variables ]
When connecting to Orbeon database, chances are credentials and other
configuration are different than the main Obsidian connection.
For example, at Nasqueron, Orbeon uses a PostgreSQL database
on a different server than our Obsidian MariaDB database.
The workspace configuration should so define a specific configuration
to connect to Orbeon database. To help to store the credentials,
we suggest environment variables or a .env file. YAML parser can refer
to environment variables defined in $_ENV or $_SERVER.
[ Keruald libraries ]
To support this application, two new features have been shipped
in the Keruald project:
- keruald/database now supports PostgreSQL
- keruald/yaml allows to parse YAML files, with !env tag support
[ Blocks to create Obsidian applications ]
Instead of creating a template specific for this application,
the output can be composed with relevant templates in _blocks,
specialized in rendering data as <dl>, <table> or title.
This is a pattern we want to encourage in custom applications development.
When an application doesn't need any custom template, there is no need
for Composer scripts to copy data to a template directory or for complex
templating registration. The monorepo pattern make also easy to add new
blocks templates at the same time than the application using them.
[ Known limitations ]
The REST API would require custom development for an authentication system.
As such, the application requires access at database level. A read-only
access is enough.
Without the REST API, we have access to uploaded file contents
but not to the metadata, hence the count attachments query.
[ What's next ? ]
The goal of this application is to be able to annotate forms,
storing the annotations directly in a Obsidian collection.
This is not yet implemented, as this feature focus on the reader part.
[ References ]
References:
- https://doc.orbeon.com/form-runner/persistence/relational-db
- https://doc.orbeon.com/form-runner/persistence/flat-view
- https://doc.orbeon.com/form-runner/architecture-and-integration/accessing-data
- https://doc.orbeon.com/xml-platform/controller/authorization-of-pages-and-services
Ref T2160