Support for multi page forms

[displacedaussie]

For one of our sites we're using Plomino but have a requirement for "multi-page" forms. Essentially we want a single "form", but we want to provide a way for the user to "work" through the form, showing one page at a time, and allowing different flows depending on previously selected options.

Currently we have this working as follows:

• Use Plomino Accordions to denote pages. Anything inside an accordion section is grouped into a page.
• Use Diazo to insert Next/Back buttons on each page. The next button "Submits" the form (triggering validation)
• Via our theme Javascript, the Next/Back buttons hide the current accordion section and show the next/previous accordion section. If a page doesn't have any visible content (because it's inside a hide when that's currently hidden), that page is skipped.
• During the validation of each page, we only show errors for fields that are on the currently visible page. If validation "succeeds" for the visible fields, we move to the next visible page.
• If on the last page and validation succeeds, the form submits as normal.

This all seems to work well, but I'm not sure whether it's functionality that should definitely stay in our theme, or if it's worth pushing it back to Plomino in some way. If it did get pushed back here, what would make the most sense for grouping content into pages?

• Use the "Page break" div in TinyMCE (has usability issues)
• Keep using Plomino Accordions
• Create a "Plomino Page" class and related TinyMCE plugin/button

Would any of these work?

Another problem we have is that our paging functionality relies on Javascript and there's no fallback for non-javascript browsers. As such, I was wondering if any of the following possible options for making this work would make sense inside Plomino, and if you have any suggestions for the best way to make this work.

• Add a multi-page view of a form (OpenMultiPageForm) that handles displaying the correct part of the form, provides paging support, passing data forwards/backwards, showing the correct hidewhens, validating the data on the current "page", submitting on the final page.

This is what I'm working on at the moment.

• Add publisher hooks to modify the response and request to do the above (could put this in a different product).
• Add an option to a Form that indicates it's a "multi-page" form and always show the "MultiPageForm" if it's select as such.
• Use multiple sub-forms that allow flow between them (passing through request data, plus showing/hiding sub-forms based on values in the request data).

Do you have any thoughts or guidance on supporting this kind of functionality?

[ebrehault]

I think that's a case that could be covered by the plomino_alternate_form feature. See https://github.com/plomino/Plomino/pull/642

[djay]

@ebrehault I think it would be a shame to keep this out of the plomino core and in a separate view as it results in a lot of code reimplementing plomino in another package.

I think it seems a reasonable feature when your usecase is longer survey type forms, or forms collecting lots of data from the user.

1. Still keeping it as a single large form
2. place accordions around each part you want to be a separate page
3. insert a continue action into each one
4. set a checkbox to make it multipage form (instead of normal accordion
5. optionally insert summary fields on the last page so you can review your answers.

Is this usecase that unique to us?

[ebrehault]

@djay yes I agree it is a quite generic use case and would be nice to have it in the core. Nevertheless, be careful, do not invest too much effort in developments involving existing JS components (like accordions, or also datagrids) as they are/will be totally rewritten in Plomino 2/Plone 5.

Note: by the way, Plomino 2 is currently released as alpha, the code is managed here https://github.com/plomino/Plomino/tree/plone5, it is working quite nicely, but we still miss few features (datagrid, hidewhen, documents import/export, accordions, cache). If you want to help, you are welcome :)

[djay]

@ebrehault Perhaps daniel didn't write it out well. The code we originally had was all JS. We've now thrown this out because we need 100% progressive enhancement, ie paging has to work without JS. So it doesn't rely on accodians per se. We were reusing the markup as a way to indicate whats on a page. We could equally have created a new button and a new kind of markup but there seemed to be too many already.

In terms of plomino 2, its a little alarming that those features are missing. Does this mean you are rewriting it rather than keeping the code largely the same? I understand that plomino wasn't going to change much. It was mainly about having to redo the tinymce integration. If its a major rewrite this affects our plans a lot.

[ebrehault]

@djay, don't worry, those features are missing at the moment in the alpha release, as I though it might interesting for people to try out Plomino on Plone 5 even if it is not 100% complete, but they will be part of the final release of course.

All the Python code have been preserved, the only changes are:

• Dexterity instead of Archetypes (basically no impact, we just need to use direct attributes instead of getter/setter, like form.form_layout instead of form.getFormLayout()),
• JSON instead of XML for import/export features (I started with XML, but it was really painful, and using JSON was so simple, so I decided to switch but we will write a JSON exporter in the future last 1.x release so we can migrate an existing Plomino db from Plone 4 to Plone 5).

Regarding JS, it is more difficult, as we cannot (reasonnably) maintain our dependency to JQueryUI and Datatables in Plone 5. The right way to go is to use Mockup, so it implies to re-write our JS features entirely. For now, my colleague @Gagaro has rewritten the plomino.tinymce buttons (directly into Products.CMFPlomino as TinyMCE is now part of Plone core, it makes no sense to provide it in a separate module), and I have created some Mockup patterns for the dynamic view (to replace Datatables), the dynamic widget for selection and doclink fields, and the formula editor (based on Ace instead of CodeMirror).

So my point was just that anything based on 1.x JS (like Datatables, or JQueryUI) will have to be changed, but your Python code should not be impacted much.

[djay]

@ebrehault so will there be an upgrade path? if you switched from xml to json then the only way would be import into a 1.x site, do the inplace upgrade and export as json? Seems a bit painful. Also if you are changing the export format, why not switch to the rapido style of using seperate files of .html, .py and json? That would be a lot nicer. And even nicer still if there was an ACE editor to could cloud edit them (ie jump around the code in one screen rather than DX/AT style)

In terms of dexterity, there is no problem with restrictedpython?

I agree moving to mockup is a good idea. As long as an unthemed site still works largely the same. One thing we were potentially going to work on was a different style of datatable that had progressive enhancement so worked even when you have no JS. The layout would be a repeating set of subforms instead of a table and the non JS would be to add a max number of rows property and just show that number of repetitions with no JS. It would be good if whatever datatable replacement you choose works ok without JS.

[djay]

@ebrehault In terms of multiple pages in plomino core, what is your feeling? given it won't involve JS.

• If we added another grouping in tinymce similar to the accordian called a page, then no checkbox would be needed.
• The plomino form as it is now would be the case where a form contains no page elements.
• When a page element is added then the form gets continue and back buttons and only a submit button on the last page.
• The hidewhens and validation are calculated on each continue but only for whats displayed on the current page.
• If you put a hidewhen to hide a whole page then that page is skipped on continue. This makes multiple paths through the pages possible.
• continue buttons can be custom placed in the same way submit buttons are.
• it's not clear yet if there is need for another formula to execute code on continue instead of submit.

[ebrehault]

Regarding the upgrade path, I have only considered the case of an existing Plone 4 site containing Plomino db, in that case you just install the last Plomino 1.x version, you export your dbs as JSON, then you setup your new Plone 5 site and you import your dbs. Here you talk about converting directly existing XML files to the new format without using Plone 4. I guess that's not too difficult to create a command-line Python script for that.

Regarding the html/py/json export splitting: the idea was to preserve our existing Python code, so for now, I prefer to stick to the old approach. Same thing for the ACE editor gloabl edition instead of content-type regular edit pages, that's too much for nos, I prefer to release a Plone 5 compliant version first.

Regarding the multipage feature: I agree with your proposal, and:

• an extra tinymce tool for grouping page content seems necessary
• I think we can use the existing onSave event to manage code to execute after Continue (we just need to pass a current_page parameter so we now we are)

[djay]

Ok, great news on the paging feature. Daniel has the code mostly done, and he'll let you see that soon to get feedback on. It's currently implemented as a separate view. After that we will move the code into a PR for plomino 1.x. Later still we will merge it into the plomono 2.x branch

the extra tinymcetool I think will likely insert a div which acts live a divider between two pages. It will contain the page title which can later be used for progress navigation perhaps. A divider is better than a div containing the page I think because its not clear what should happen to content outside of a page.

In terms of events, thinking about it more onSave doesn't seem right. The ondocument_create is the one that calls on normal page loads so its the best place to do custom code on continue.

Ah, I see, so there will be a plone 4 version with json export. That helps. No need for a commandline version. Not sure why html/py/json splitting requires changing the python code much. You can still keep the existing object model etc. It's just an extra transformation on import. parse the python and split it into relevant formulas, put the html into a rich text field etc. The reverse on export. I don't think you need to save the original upload files. Perhaps just make a rule that any code above a function gets put into a special comment at the top of the formula, or removed? The same thing is true for an editing environment. Each save work out which object/attribute to update and perform a DX save in the background. The big win however is that if we agree that having .html and .py is where we want to go eventually, having the pain of 2 formats is less than the pain of 3 formats. We keep our plomino code under source control. Its not great having it completely change on you between upgrades.

[ebrehault]

I hear you, but my mid-term objective is to remove all the code from the Plomino interface, I want it to be very approachable for non-developers, so modify the application behavior by editing content-types sounds like a good strategy to me. And to handle the complex parts, the needed Python/JS/HTML code would be handled in Rapido by actual developers, where we already have an editor, and separated export formats, etc.

Note: About ondocument_create: you are right.

[djay]

I'm not sure what you mean by remove all the code from the plomino interface. Plomino doesn't work without formulas. Where does that code go?

[ebrehault]

I do not want formulas to be visible/editable from the Plomino interface. The developer would work in Rapido to implement the formulas (like field formulas, or form events, etc.), and he would also add extra information to reference those formulas properly (like: this is formula which provides a value list for a selection field). In Plomino the user would not need to write a formula to compute his selection list values, the interface would look up into rapido, find all the appropriate existing formulas, and the user would just pick the one he wants.

That's the idea.

[djay]

not so sure about that. Sounds like an extra indirection step which makes things more complicated. I initially thought valdiation forumulas, field formulas and hidewhens would be too complex for non technical users. Turns out they are a bit, but not nearly as much as I thought. An these formulas are tightly bound to the fields and forms themselves. So separating that doesn't make a lot of sense. I think the idea of a wizard code generator for certain kinds of common patterns is good so they can get started more quickly is good. But making people jump around the UI even more to write formulas sounds like its making the UX worse.

[ebrehault]

Yes ok, we should probably preserve a mode where formulas can still be edited from Plomino, but the idea here is not jump around the UI but to offer a dedicated tool to each public:

• non-developers in Plomino
• developers in Rapido And by the way, an entire Plomino app could be probably build from Rapido without editing the db object itself, so you do not jump around, you just stay in Rapido.

[djay]

Yeah I see what you are saying. It would be good to hide the more app kinds of code. But based on recent experience I think the line between developer and non developer is more blurred than I expected. To hide all the field formulas would mean we would have to replace them with a lot of ui such as all the possible ways to do validation. Same with hidewhens. We somehow need to have a easy learning curve between easy validations and hidewhens and complex ones. I think perhaps all form formulas might be classified as advanced.

On Wed, 9 Sep 2015 18:41 Eric BREHAULT notifications@github.com wrote:

Yes ok, we should probably preserve a mode where formulas can still be edited from Plomino, but the idea here is not jump around the UI but to offer a dedicated tool to each public:

• non-developers in Plomino
• developers in Rapido And by the way, an entire Plomino app could be probably build from Rapido without editing the db object itself, so you do not jump around, you just stay in Rapido.

— Reply to this email directly or view it on GitHub https://github.com/plomino/Plomino/issues/657#issuecomment-138884839.

[djay]

One extra thing we need advice on for multipage forms. We have a feature we need called summary pages. This is where on the last page, or the bottom of the current section/page, you can display list or table of what you've entered along with a link back to the page so you can change it. How we've currently implemented this is with a span style called summary, which turns that into a field title, field value and the link. You have to create them for all the fields on your form because you might like to include only important answers.

However, we've thought of some alternative ways to implement this that might be more generally useful. For example of there was such a thing as a dynamic computed field. A field that could be calculated without the form having to be saved. This is similar to the summary field. However we would still need a way to insert a link that goes back to change the value. Any ideas?

[ebrehault]

Well, I already thought about such a dynamic computed field, it would be quite similar to the dynamic hide-when mechanism (I think the JS code would be 99% similar, and we might probably make only a single AJAX request to get both dynamic hide when and dynamic fields data). So yes, definitely, let's do that.

[djay]

Yes thats what we were thubking of. Useful outside of the summary usecase. What about the link back to to change the value? We could either make it a special kind of dynamic computed field where you specify the field its value comes from and tick a box that says "include link to change value". Alternatively we would have to include a special link element with a fieldid which creates a link back to the right place. Maybe we could use anchors for this. Still this is extra work to create a summary page. Now you have to create three elements for every field. Label, dynamic computed field, and link to field.

On Thu, 10 Sep 2015 23:01 Eric BREHAULT notifications@github.com wrote:

Well, I already thought about such a dynamic computed field, it would be quite similar to the dynamic hide-when mechanism (I think the JS code would be 99% similar, and we might probably make only a single AJAX request to get both dynamic hide when and dynamic fields data). So yes, definitely, let's do that.

— Reply to this email directly or view it on GitHub https://github.com/plomino/Plomino/issues/657#issuecomment-139291995.

[displacedaussie]

I've submitted a WIP pull request over at #663

[ebrehault]

Hmm I think I am lost, I do not understand why we would need 2 fields here (one providing a value, and a second one having a link to the first one). I imagine something totally similar to Hide-when: you create a regular computed field, by default it will be rendered only once, when we open the form. But if we check the "Dynamically rendered" option, the field value is dynamically refreshed everytime the user changes something in the page (we just watch onChange JS events to make an AJAX call). That's why I said we could use the same AJAX request as dynamic hidewhens.

But maybe I haven't fully understand your need and my solution is not accurate.