How to manage multiple versions of form

[fulv]

This is a follow up to a question I asked Eric in Brasilia, and I wanted to put it here for future reference, since I have not found any resources on this topic.

I have a Plomino application centered around documents created by a single, main, complex form, submitted by customers of the system's owners. This form has to be resubmitted every year by the customers, and the forms themselves need to change slightly year after year. For this application's purpose, I'm not too concerned about schema-incompatibility of different versions of these forms.

So I'm wondering about the best approach to structure the application such that it could handle this requirement. The application needs to store all the documents submitted by customers over the years, but the documents need to open with the version of the form that was in force at the time it was submitted. Here are three different approaches I can think of:

• Put the logic for selecting a year-appropriate form into the main form, e.g. by using a computed redirect field. The computation would look up another field that contains the year to which the document pertains. So all documents would have the same Form value, but would redirect on open to the right form for the year. The downside is that any other logic elsewhere in the system that depends on the form being used might need to be made aware of all the year-specific forms, because calling getForm() on a document opened by redirecting to a year form would return that year form.
• A different variation of the above would be to have the main form composed of one or more subforms. The subforms could be made year-specific, and the selection logic could be put in the main form by computing a different href for each subform. I believe this is the approach used by @robystar. However, I can't think of a way for computing the subforms' hrefs.
• The approach suggested by Eric, as I understand it, is to create a different Plomino database for each year. However, it's not obvious to me how to write common logic to access all the year-specific databases from the central database. For example, how would I create a view returning all the documents for all available years specific to one customer?

I would appreciate any comments, suggestions or references to existing resources on this topic.

[ebrehault]

If you need to access all the docs (from the different years) at the same time, multiple databases are not ideal (even if can still show documents in a computed for display datagrid field that will list all of them).

Another approach could be to create an archiving mechanism: let say your current form is named frmMarket, and you create some docs with it, at some point, you launch the archiving agent that would:

• copy frmMarket as frmMarket2013,
• change the Form item of all the docs where Form=="frmMarket" to frmMarket2013 and then you can modify your frmMarket form, create new docs with it, and your old docs are not impacted.

[jean]

I'd be interested how you solve this. It could be a good lesson in Plomino application design. One tactic I haven't seen mentioned: ensure that customers access docs via a view. I.e. they browse to .../someview/somedoc. The view has a Form formula which makes sure docs open with the right form. All links to such docs in the application must include the view.

Easiest is if the form is correct already:

• Forms are year-related, so name them for the year to begin with. No need to redirect or rename stuff later.

Other notes:

• never depend on the Form item of your documents, it's used internally by Plomino. You and Plomino will only end up fighting about what it's supposed to mean. Define e.g. doctype instead, and compute the form to be used based on other context, e.g. doctype + submission_year. The same goes for creation/modification date. If you treat creation date as though it was submission_year, you suffer if you ever have to import old docs, or export/import to a new database, etc.
• Plomino sets the Form item before processing form fields. So you could define a computed Form field which sets the Form item the way you want it, overriding the value set by Plomino. This would be an alternative to the view approach. @ebrehault , is this OK? You'd have to be careful, e.g. if formulas depend on Form, you'd have to make sure that the Form field is first in the layout.

The edge case is where you need to add docs for a previous year. For this, define a form where you can select the year, and an action which goes to the correct form based on the year.

[fulv]

@ebrehault So, I was able to access one db from another by doing this in a computed for display field:

portal = context.restrictedTraverse('@@plone_portal_state').portal()
db = portal.restrictedTraverse('vendor-management').getParentDatabase()
search = db.getIndex().dbsearch({"Form": ["frmFarmer", "frmProcessor"],})
...

where vendor-management is the "other" db.

Is this the best way, or is there a better one?

[fulv]

@jean Thanks for the tips! The view Form formula tactic was already suggested by @ebrehault in #444. I just tried it, and it works great, I think my strategy will revolve around this technique.

The reason why I am looking into this is that I have already built quite a bit of application logic that depends on looking at the Form item, because I have two similar, but distinct types of customers who use different forms, on top of the other forms to handle other application-related content. (Yes, above I said single, main, complex form, but in reality it's two main, complex forms). So in a sense I treat the Form item as a class (in the OO sense), and want to subclass year-specific forms, but have the underlying logic apply in the same way to all subclasses of the main forms. Thus, having the forms named for the year to begin with is not an option.

Maybe this is what you are warning me about re: depending on the Form item of my documents? I suppose I could use a doctype item to act as the Class of my documents, but I'd have to change all my logic to use it. I will use a submission_year-like item to identify the year, that's for sure.

I do not have to add documents for a previous year. Input happens only for the current year, but previous years need to be viewable and reportable all together.

The computed Form field idea sounds scary =-O, but if @ebrehault says it will work, it might be interesting.

[jean]

access one db from another

I generally do this (maybe @ebrehault showed me):

plone = db.portal_url.getPortalObject()
somedb = plone.somedb

I'd have to change all my logic to use it

Search'n'replace in an XML export of the database ;-)

I do not have to add documents for a previous year

Never say never ;-)

[mamogmx]

I am interested too in the solution of this problem. We have some cases where we need to render a document with various forms in function of some parameters (eg workflow state, roles on the document, etc.). Really don't know if it helps but the solution that I would like to take is not very elegant but it should be functional for our needs. Customize the edit/view templates of documents in order to accept a formula returning the form instead of current form instead.

Marco Carbone (Gis&Web developer with robystar)

[jean]

@mamogmx why would you not use the view Form formula? It sounds like a good fit for your case.