PUT
/fr/service/persistence/crud/$app/$form/(data|draft)/$document/data.xml
GET
/fr/service/persistence/crud/$app/$form/(data|draft)/$document/data.xml
PUT
/fr/service/persistence/crud/$app/$form/(data|draft)/$document/data.xml
DELETE
/fr/service/persistence/crud/$app/$form/(data|draft)/$document/data.xml
$app
is the form definition's application name$form
is the form definition's form name$document
is the form data's document idOrbeon-Operations
response header lists the operations that the user can perform on the data (see Supporting permissions in your persistence API implementation).Orbeon-Form-Definition-Version
request header tells which version of the form definition is requested.Content-Type
must contain the content-type of the resource to store. For XML in particular, pass application/xml
.Orbeon-Form-Definition-Version
header.form.xhtml
, data.xml
), the persistence layer must return an appropriate XML content-type: application/xml
, or application/xhtml+xml
.PUT
ting data under the path /orbeon/builder/data/
, which means storing unpublished form definitions and form definition attachments, always set Orbeon-Form-Definition-Version
to the value 1
, or omit the versioning header (which defaults to 1 for new data, and to the latest version of the resource for existing data). This is because Form Builder stores its unpublished form definitions like a regular published form would, but in effect there is only one "version" of Form Builder.PUT
to update a resource (whether form data or attachment), the built-in relational persistence layer checks that the version number provided matches the existing version number in the database. Custom persistence layers should do the same.PUT
an attachment with path (indented for legibility):400
"Bad Request" HTTP status code.<xf:bind>
elements can be present.form-definition-format-version
, is provided. It applies to the GET
method only, in the following cases:Orbeon-Form-Definition-Version
header to specify the form definition version):form-definition-format-version
is used, the form definition is partially migrated to match the specified destination data format:form-definition-format-version=4.0.0
: target the 4.0.0 data formatform-definition-format-version=4.8.0
: target the 4.8.0 data formatform-definition-format-version=2019.1.0
: target the 2019.1.0 data formatupdated-with-version
or created-with-version
metadata, that information is used to infer the data format associated with the given Orbeon Forms version.fr-form-instance
-template
instances)$app
): acme
$form
): order
$doc
): fc4c32532e8d35a2d0b84e2cf076bb070e9c1e8e
PUT
form data as follows:GET
method is used implicitly by curl):orbeon/builder
app/form names. So with the following assumptions:$app
): orbeon
$form
): builder
$doc
): 7b55c9d6f9b058376293e61d9f0d4442e379f717
PUT
a form definition so that it's available to Form Builder:GET
method is used implicitly):nonrelevant
GET
for data onlyremove
: remove all XML data elements with attribute fr:relevant="false"
keep
: [SINCE Orbeon Forms 2018.1] do not remove XML data elementsfr:relevant="false"
annotation.valid
PUT
onlytrue
: data sent satisfies validation rulesfalse
: data sent does not satisfy validation rules/crud/orbeon/builder/data/$doc
acme/order
with a single attachment (for example for a PDF template or static image):PUT /crud/orbeon/builder/data/7b55c9d6f9b058376293e61d9f0d4442e379f717/a29fd47011b2957ef44a62d92995adfdbae03fa9.bin
PUT /crud/orbeon/builder/data/7b55c9d6f9b058376293e61d9f0d4442e379f717/data.xml
PUT /crud/acme/order/form/a29fd47011b2957ef44a62d92995adfdbae03fa9.bin
PUT /crud/acme/order/form/form.xhtml?document=7b55c9d6f9b058376293e61d9f0d4442e379f717
Orbeon-Form-Definition-Version
header with values:1
if there is no published versionnext
: to indicate that the form definition must be published under the next available versionPUT
and GET
PUT
request for each attachment. Conversely, to read an attachment that has been saved, use a GET
to the attachment path. The format of the attachment path is as follows, on a single line (here split in multiple lines for readability):$attachment
is a random id for the attachment. The .bin
extension is expected.GET
request and aren't expected to do the encryption themselves when issuing a PUT
request. This ensures that the persistence API is as simple as possible to both implementers and users of the persistence API.PUT
), you must "tell" the persistence proxy what field this attachment corresponds to, so the persistence proxy can figure out whether it needs to be encrypted based on the form definition. This is done by adding an Orbeon-Path-To-Holder
header to your PUT
request. The value of the header is the path to the element in the XML data that corresponds to the attachment currently being stored. The path should skip the root element name (/form
), but include "iteration" elements for repeated grids and repeated sections. For instance:personal-information
, with an attachment field photo
, then the value of the header should be personal-information/photo
.children
, with a repeated grid named child
, with an attachment field photo
, then the value of the header should be children/child/child-iteration/photo
.GET
), you must "tell" the persistence proxy whether the attachment was encrypted. You can know this by checking whether the element in the XML data that corresponds to the attachment has an attribute fr:attachment-encrypted = 'true'
. If so, you need to add the header Orbeon-Decrypt: true
to your GET
request. (The fr:attachment-encrypted = 'true'
attribute in the XML data is automatically set or removed, as appropriate, by the persistence proxy when the data is saved.)DELETE
to: