Components

Within this addon, a collection of UI components is available. These components are dynamically displayed based on the provided displayType. In other words, the displayType parameter determines which UI components are presented, offering flexibility and customization to suit specific needs.

All display types are listed here

Registering new form field components

If your app wants to support display types that aren't supported by the built-in components you can use the registerFormFields util.

The utility accepts an array of objects with the following structure:

type FormFieldRegistration = {
  displayType: string;
  edit: Component;
  show?: Component;
}

The "show" component is optional. If it isn't provided we fall back to the edit component. This allows you to use a single component for both the "edit" and "show" states of the form which is useful when both variants aren't that much different. The custom component receive the same arguments as the built-in components so you can use @show if you need to conditional behavior based on the form state.

Registering components can be done wherever you want, as long as it's done before the form is being rendered.

Note: It's not allowed to register components with a display type that's already handled by one of the built-in components.

Usage example

import { registerFormFields } from '@lblod/ember-submission-form-fields';
import SomeFormFieldComponent from 'project/components/some-form-field-component';

registerFormFields([{
  displayType: 'http://some-display-type-uri',
  edit: SomeFormFieldComponent
}]);

RDF form

The RDF-form serves as the starting point for utilizing these components, such as displaying a TextArea field. You will use this component in your .hbs file and provide the expected parameters to it.

{{!--  RDF form example --}}
<RdfForm
  @groupClass="au-o-grid__item"
  @form={{@form}}
  @graphs={{@graphs}}
  @sourceNode={{@sourceNode}}
  @formStore={{@formStore}}
  @show={{this.formConfig.isReadOnly}}
  @forceShowErrors={{@forceShowErrors}}
  @useNewListingLayout={{true}}
/>

Config files (.ttl)

To prepare for the visualization of fields and other elements, the first step is to create the necessary config files that will be added to the formStore. In most cases, our stores rely on two key files:

form.ttl: This file is used to define the structure and appearance of the form. It specifies how the form should be laid out, including the arrangement of fields and other components.

meta.ttl: The meta.ttl file will contain all metadata/ data that we need to show specific items for example what a field's predicates and default values are.

Graphs

The store will have three graphs in these graphs we will separate our config files so we can create a form that is using parts of these configs. Most graphs will speak for themselves but we will shortly go over them:

formGraph: We will be parsing our form.ttl in here which will help on creating our form.

metaGraph: The metagraph will contain the content of meta.ttl this information can be used for adding values or options to components.

sourceGraph: The sourceGraph is the graph where we put our final form togheter with the information from the other graphs. When parsing the data into the graphs this can contain a default form.

import { ForkingStore } from '@lblod/ember-submission-form-fields';
import { NamedNode } from 'rdflib';

const FORM_GRAPHS = {
  formGraph: new NamedNode('http://data.lblod.info/form'),
  metaGraph: new NamedNode('http://data.lblod.info/metagraph'),
  sourceGraph: new NamedNode(`http://data.lblod.info/sourcegraph`),
};

let formStore = new ForkingStore();
formStore.parse(formTtl, FORM_GRAPHS.formGraph, 'text/turtle');
formStore.parse(metaTtl, FORM_GRAPHS.metaGraph, 'text/turtle');
formStore.parse(dataTtl, FORM_GRAPHS.sourceGraph, 'text/turtle');

Next up Form