Template versioning and attachments

I'm having problems with attachments to form templates with versioning enabled.

My persistence layer is written to support versioning. I do need to know what the template version number is when an attachment is fetched which I expect to find in the orbeon-form-definition-version request header.

I can create two versions of a template with a different static image attached to each (versions are 1 and 2).

When I create new forms from either of the two versions of the template I get the correct static image attachments. The 'new' url to create the form and the subsequent sequence of calls to my persistence layer are as follows (the "test" query parameter is one we use internally). I've also shown the value of the orbeon-form-definition-version request header when it is in the request.

This sequence is for version 2 of the template

GET  /orbeon/fr/CPF/aaaa-test:2/new?test=true&form-version=2

GET  /persistence/cpf/crud/CPF/aaaa-test:2/form/form.xhtml
            orbeon-form-definition-version: 2

POST /persistence/cpf/search/CPF/aaaa-test:2

GET /persistence/cpf/crud/CPF/aaaa-test/form/2dc2f443696b79d9f4759553315307f8a5038189.bin
            orbeon-form-definition-version: 2

And this one is for version 1.

GET /orbeon/fr/CPF/aaaa-test:1/new?test=true&form-version=1

GET /persistence/cpf/crud/CPF/aaaa-test:1/form/form.xhtml
            orbeon-form-definition-version: 1

POST /persistence/cpf/search/CPF/aaaa-test:1

GET /persistence/cpf/crud/CPF/aaaa-test/form/98cbc8279aa7396942fe5a84ae2618827d078f93.bin
        orbeon-form-definition-version: 1

Now, when I try to edit the two different versions I get different results. If I edit version 1 it is fine, if I edit version 2 I don't get the attachment. The reason is that the value of the orbeon-form-definition-version request header is wrong. It seems to always be 1 when editing a template.

This is the sequence of requests when I edit version 1 (this one shows the correct attachment in the editor)

GET /orbeon/fr/orbeon/builder/edit/1417:1?form-version=1

GET /persistence/cpf/crud/orbeon/builder/data/1417:1/data.xml

GET /persistence/cpf/crud/CPF/aaaa-test/form/98cbc8279aa7396942fe5a84ae2618827d078f93.bin
            orbeon-form-definition-version: 1

But when I edit version 2 I don't see the attached image

GET /orbeon/fr/orbeon/builder/edit/1417:2?form-version=2

GET /persistence/cpf/crud/orbeon/builder/data/1417:2/data.xml

GET /persistence/cpf/crud/CPF/aaaa-test/form/2dc2f443696b79d9f4759553315307f8a5038189.bin
            orbeon-form-definition-version: 1

Note that when orbeon tries to fetch the attachment (and the id is correct) it is telling me that this if for version 1 of the form, but I'm editing version 2. There is no such attachment for version 1.

I know that the id for the attachment is probably unique and I might be able to use that without a version to find it but my persistence doesn't work that way. The form template and its attachments are kept together.

Is this a bug or do I need to re-think how I store the template attachments?

thanks,
brian...

Hi Brian,

Yes, this is a bug, which also happens with the built-in implementation of the persistence API. I've created:

https://github.com/orbeon/orbeon-forms/issues/3170

This is interesting, and we'll give some thoughts as to how this could be fixed. In the meantime, if you need a quick workaround, in your implementation of the persistence API, maybe you could ignore the version number when attachments to published forms are retrieved. You'll let me know if this "works" for you (in the sense that the image loads, not that this is clean!).

Alex

Thanks for confirming that Alex, I was worried that I had misunderstood how this should work.

I have a work around for the moment, when asked for a form attachment I am ignoring the value in the header (as suggested) and just search all versions in my persistence store, backwards from the latest version. This seems to work for now and should be reasonably efficient in most real world cases since the latest version is usually the correct one.

Your ticket talks about a library form but that is not my case, I don't use library forms. In my case it is just two versions of a single form template with a static image attached. I haven't tried it but I assume this will also fail for other attachments to form templates.

Hi Brian,

The ticket is about the "library", because my understanding was that
you were talking about section templates in your description of the
issue. Are you saying that you're also seeing a problem if you don't
use any section template in your form?

Alex

On Tue, Apr 18, 2017 at 7:53 PM, bwallis42
<[hidden email]> wrote:
--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

That's right, we don't use section templates (yet).

This is purely for a form template with an attached static image (or other attachment). The scenario I described above only involved a form template.

Am I using the terminology wrong? We refer to forms and form templates to distinguish between an actual instance of the form data and the template defining the controls and layout of the form.

brian...

Hi Brian,

Indeed, I thought that by "template" you were referring to "section template". Well, that misunderstanding was a chance to find another issue, even if not the one you're seeing.

I read again your original message. Let's see if I understand it properly this time. The issue is that you're editing a form in Form Builder, passing a form version parameter (?form-version=2). When editing a form, the version number you're passing refers to the version of the form used for editing (in this case orbeon/builder, i.e. Form Builder), not the data being editing (in his case id 1417, which in the case of Form Builder itself is a form). So you're saying: "edit this form with version 2 of Form Builder", which in the context of Form Builder doesn't make sense, since there is only one version of Form Builder.

I think that implementing #2777 (link below) would help with this. Or am I again misunderstanding what you'd like to do? :)

https://github.com/orbeon/orbeon-forms/issues/2777

Alex

OK, seems I've also misunderstood how this works. It hadn't occurred to me that the form-version parameter referred to the version of the builder. Of course that makes sense now that I think about it, the builder isn't special, it is just another, rather complicated, form.

So my problem comes from our overloading of the form id, the 1417:n value in the URLs, with some version information which is the 'n'. We support multiple versions of the form definition using this mechanism but this version id is not available when an attachment is fetched. i.e. When I edit the form definition identified by 1417:2 Orbeon fetches two objects from my persistence layer, one is the form definition xml file and the other is the attachment. The two urls used are

GET /persistence/cpf/crud/orbeon/builder/data/1417:2/data.xml

GET /persistence/cpf/crud/CPF/aaaa-test/form/2dc2f443696b79d9f4759553315307f8a5038189.bin

What I need in the second get is the version number from the first part, '2', but is isn't available. My misunderstanding led me to thinking that it would be in the orbeon-form-definition-version parameter. But of course it isn't as that is referring to the version of the builder form definition (correct?).

Since the attachment ID is unique (correct?) I can probably just keep all the attachments for the forms together in the one place for a given form definition and not worry about the version of the form definition when fetching attachments.

thanks, will think some more about this.

brian...

Hi Brian,

Interesting. How do you get such an ids, i.e. 1417:2 instead of the the random id generated by Form Runner? And how do you create a new version? I imagine that this would entail "copying" the form definition and PUTting it back under another id, say to go from 1417:2 → 1417:3, but how is this done?

Also, on a separate note, Form Runner currently doesn't "update" attachments. If users were to change an attachment in Form Builder, it will when stored get a new id. So you maybe don't need to worry about the version when retrieving attachments. If you have both 1417:1 and 1417:2 pointing to the attachment 879.bin, you know that it is the same file.

Does this make sense?

Alex

Alessandro Vernet wrote

Interesting. How do you get such an ids, i.e. 1417:2 instead of the the random id generated by Form Runner? And how do you create a new version? I imagine that this would entail "copying" the form definition and PUTting it back under another id, say to go from 1417:2 → 1417:3, but how is this done?

We assign an identifier from our store when the form is saved and then just use that ID when we ask form runner to edit  a form. Our IDs are also returned from search requests. Everything pretty much works from there. We do need to cache attachments prior to saving a new form since they are sent before the form and we don't have an ID assigned yet and we also do id substitution for attachment paths on the form source xml when it is saved since the original identifier is in that path.

It all seems to work pretty well but can be a bit confusing at times, even to me :-)

Also, on a separate note, Form Runner currently doesn't "update" attachments. If users were to change an attachment in Form Builder, it will when stored get a new id. So you maybe don't need to worry about the version when retrieving attachments. If you have both 1417:1 and 1417:2 pointing to the attachment 879.bin, you know that it is the same file.

Does this make sense?

It does. And that may be the approach we will take in the future. For now we have a working version where we copy all the attachments for each new version and then prune the set based on looking at the form definition source to remove unused attachments.

thanks, brian...

Hi Brian,

Got it, and your current approach seems rather clean, as you end up with the attachments being "together" with their form, and only have stored the attachments you need. So, in addition to working ;), what you're doing sounds good to me.

Alex