Database Reference
In-Depth Information
We use the POST method here for our xf:submission instead of the
PUT method used in Example 10-4 as the REST Server in eXist does
not support stored query execution via HTTP PUT .
The disadvantage of the approach in Example 10-5 is that if the same user completes
the form twice or hits Submit twice, you will end up with two XML documents in the
database collection containing (most likely) the same instance content. There are
many different ways to attack this problem, but they all involve being able to identify
the user. Two possible approaches are as follows:
• Have the user add a uniquely identifiable piece of information to a form field.
When the form is submitted, you can check if this information from the instance
is already present in the database; if so, you can fail the submission by returning
an HTTP 403 Forbidden error code (e.g., response:set-set-status-
code(403) ).
• Set up authentication and appropriate permissions, and have the user log in via
XQuery before allowing her to access the XForm. In this way a session will be
created on the server. You can use the username to determine if the user has
already created a document in the /db/registration collection. If she already has a
submission in the collection, simply return a 403 Forbidden response to the
form submission.
In combination with this approach, you could generate the XForm using XQuery
(as simply as calling doc ). If the user already has a submission in the collection,
instead of showing her the form, you can display a message or redirect the user to
another page.
For further details on calling stored queries via the REST Server, see “Executing
stored queries” on page 335 . As an alternative to stored query execution via the REST
Server, you could instead submit an XForm instance to a URI provided by a RESTXQ
resource function, as discussed in “RESTXQ” on page 353 .
Search WWH ::




Custom Search