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