Orchardcore: Insight into how complex an OrchardCore.Form can get?

[remesq]

Working with O1 recently and I ran into a rather frustrating problem. I have a bunch of complex forms in which I use jQuery to show/hide and enable/disable form inputs based on certain conditions (e.g., radio button with Yes > opens a new question, with No > either move on or present a different question, etc.).

This weekend, in preparation for moving to OC, I was expanding some of my O1 forms while I anticipated it would take a while to move to OC. On Saturday, I created a number of new inputs, published both the Content Item and a Template containing my jQuery. Sunday I started working again and noticed all my work from the prior day was not available. Using Audit Trail, I saw that my Content Item had been edited 22 hours prior, but in fact it was more like 10 hours. So all of that work was missing. At first I thought I messed up and did not publish. I spent Sunday redoing the work and made sure to Save then Publish the work but not before exporting my site, wiping the ~/AppData folder in development, and importing it into a new site (I thought maybe the DB was corrupt).

Monday I started working again and noticed the exact same thing. All the work I did Sunday was not there. Audit Trail showed the Content Items were worked on 22 hours prior; again, it was more like 8-10 at this point.

The forms probably had 20 basic questions, another 30 based on conditions. Using Layouts I had a lot of extra HTML markup interspersed with the form inputs (headers, text to explain, etc.). I did notice the Content Item using Layouts was getting sluggish in terms of responsiveness.

However, I've decided to just push ahead with OC but am now wondering what, if any, is the upper limit of form inputs and other elements on a Content Item? Not sure if there was just a memory limit in O1, or some other known issue that I was unable to dig up. My concern is that using Flows, maybe some custom widgets to customize the CSS (or .cshtml override templates, Admin Templates, or a mix), that I'll overload a Content Item and run into this problem again.

While I have thought of just creating a Module to handle it all, it seemed like a lot of work for something that OC seems capable of handling - plus the fact that I'm not a developer by trade.

TL;DR: Does anyone have any insight into how complex OrchardCore.Forms can get, and whether or not there is a limit on the amount of elements (Widgets, Form Inputs, etc.) that a Content Item can contain?

[sebastienros]

If you think creating a complex form is more work in OC that in a custom cshtml, then I can't suggest you to use the OC feature. It might be risky if you don't know the scope of these forms. Then if they really have to be "dynamic" you should try the most complex version it could get to.

[remesq]

If you think creating a complex form is more work in OC that in a custom cshtml, then I can't suggest you to use the OC feature. It might be risky if you don't know the scope of these forms. Then if they really have to be "dynamic" you should try the most complex version it could get to.

I believe the opposite, I believe that it would be easier to do in OC (especially now that I've had a few more weeks to work with it). My main concern was a problem I encountered with O1 - forms just wouldn't accept any more fields. I would save additional fields and then if I left my session, they would not have been saved to the next session (like if I shut down at night and came back in the morning). I don't know if that was some limit like in https://github.com/OrchardCMS/OrchardCore/issues/3422, or if it was the Layouts module in O1 that couldn't handle all the rows/fileds/etc.

I've not tested an upper limit yet with OC forms in terms of how many fields, etc., one form can contain. My forms may have about 50 questions in total, but only 20 are exposed at the beginning and through conditions some of the other 30 are displayed.

[willnationsdev]

@remesq Did you ever find out more info about this? I work on developing very similar forms in PHP using a custom framework. Our team is interested in porting those apps to Orchard Core, but this Issue raises some eyebrows on whether we'd need to write a custom solution again.

[jptissot]

I am working on a forms module here: https://github.com/StatCan/StatCan.OrchardCore/pull/53 if anyone is interested. I'm hoping to have some basic version ready by then end of next week.

[remesq]

Awesome @jptissot! Could you share some insight into where you are going with it? I've started creating a custom module to handle forms I had on O1 and it's really daunting. Primarily, I am concerned about lists (radio button lists, checkbox lists, dropdown lists), which I could not really get to work with OrchardCore.Forms.

I used your examples here https://github.com/OrchardCMS/OrchardCore/issues/6245 to get myself started. But I ran into issues with checkbox lists, specifically returning state after validation errors. I mentioned my problems in the following two issues I posted:

1. https://github.com/OrchardCMS/OrchardCore/issues/6472
2. https://github.com/OrchardCMS/OrchardCore/issues/6667

[remesq]

@remesq Did you ever find out more info about this? I work on developing very similar forms in PHP using a custom framework. Our team is interested in porting those apps to Orchard Core, but this Issue raises some eyebrows on whether we'd need to write a custom solution again.

As I mentioned directly above, I started thinking I would have to create a custom solution for myself. OrchardCore.Forms is not complete. It will work well with Workflows to handle simple forms, but anything more complex with conditions and dealing with lists (like enums), it requires more work. This is unfortunate, as something like O1's Dynamic Forms really worked well for what it did and I personally think OC needs something along the same lines to make working with sites easier for people like me who are not developers.

In my case, I try to find good solutions that I can mimic and then just use repeatedly; but this gets complicated without something like a forms module to do the heavy lifting. I'd much prefer using the backend of OC to create forms as opposed to creating large custom modules for my forms.

[jptissot]

@remesq My forms module aims to simplify some things compared to OC's built in forms module. Namely:

• Easily support client / server side validation with the help of jquery.validate.unobstrusive library without the need of a workflow
• a11y built in
• Ajax validation and submission
• Worfklow hook on form submission
• Client side OnChange function defined in the admin to add custom show / hide logic for form inputs
• A field to write a script when the form is valid and submitted to run custom logic without needing a workflow.

Other than, that. Long term goals would be to allow to easily store submissions in a generic way.

[sebastienros]

@jptissot I read you code and I don't understand the fundamental differences between the current module and yours. They both use a form part, and form elements as widgets. What is deserving a custom module?

[jptissot]

@sebastienros It was mostly to add ajax submission to a generic controller to allow the form module to use inline scripts for validation and submission logic.

[ns8482e]

@jptissot I guess same can be achieved by overriding Form.Wrapper.cshtml and providing script for ajax submitting.

And I remember once @sebastienros suggested to add wrapper per ContentType - will work on it once I get some time.

IMHO - there seems be a need of having form-break widget in Forms module that would break form in multiple UI screens ( all using javascript) that would render next/prev button - However submission will still be all at once.

[jptissot]

I merged the VueForms module today. Docs