We are planning to do another round of improvements to Umbraco Forms. We know that many of you are still using Contour on your Umbraco v7 installations, we are very interested to know why you prefer to use Contour instead of Forms.
By getting your answers we'll have a clear idea which features we should focus on adding into the Umbraco Forms product.
Is there any way we can have different versions of the JSON data files? Say for local debugging, staging and production? Something that is detected via VS Debug/Release modes or via the web.config would be awesome!
Reason...I dont want workflows going to live email addresses when debugging locally.
Hmm, does Forms re-create them at runtime? I thought they were a complete replacement for what was in the database schema? So if they don't get copied, wouldnt you have to manually re-create them in the UI? Or are you suggesting switching them out for versions stored somewhere else?
@Martin, you can still right click the folder and publish if you use VS and web publish.
We've got editors working on forms in the production site, so we rather download them for development instead of deploying them from development. :)
The main reason I use Contour rather than Umbraco Forms is that my company has a library that is built against the Contour DLL's that I'm not sure would work against Umbraco Forms (it very well may, but my assumption is that it won't).
That thread might also be worth reading for some deficiencies in Contour. Perhaps you can rectify them in Umbraco Forms.
I agree with what somebody already said regarding the forms being on the file system. While awesome for source control, it makes doing per-environment changes challenging. One idea that comes to mind would be the ability to enable/disable forms per-environment (i.e., the form would be on the file system, but the toggle would be in the database). I suppose another option would be to gitignore the folder that stores the forms (but then the forms wouldn't be source controlled).
We'd hit the Contour APIs fairly hard and I had to do quite a lot of work to get them running in forms.
Apart from a lack of granular user access, it pretty much does everything we had in Contour. The codefirst methods are a loss, but I dont mind that as the JSON files do the trick nicely.
Personally, I would just like to know what the differences are between Forms and Contour....sometimes I am on a Forms page, next click I am on a Countour page....etc. A simple high level explanation of the differences would be really helpful and would have saved me half a day of building out forms that won't do the job at the end of the day. Would really love to see member update and member create workflows....
Hi I've thought of another improvement in view of my question about file deployment...
Can we have a switch in the UmbracoForms.config to change the output files from Json to XML allowing for Forms to read XML as an alternative format.
Reason being, in VS I can then create a template file and instruct studio to transform the necessary parts for debug and release modes upon build and deploy!
This would be an extremely handy feature, plus I still personally feel XML is more readable in situations like this. :-)
+1 to Martins suggestion.
The storage provider should be abstracted and exposed so we can choose json or xml, and possibly also implement our own. (Database for instance)
We're asking because we're adding new people to the Forms team to make sure it gets up to speed on the features people need for an editor focused Form builder.
I hope that the team is also taking a look at the issues-list on http://issues.umbraco.org/issues/CON. We've created a few issues in the last couple of months, since we've started really using Forms.
Most of them are small issues for better HTML5 and accessibility-compliance (or at least the possibility to do this as a developer).
We've just had an issue where we deployed an update in Azure to a "UAT" slot and then swapped slots to make those changes live. Unfortunately the client had created a new Form in the Production slot and hence when we swapped slots that new form (and any changes to the other forms) were swapped to now be in UAT.
I've had a few issues like this which may have other solutions but it would be good if this type of thing were persisted to the database (which we currently share across both slots), or optional abstracted file system provider in much the same way you can with the Media directory.
For now we're going to have to manually copy the JSON schema files between slots to ensure we have the latest files.
At the moment, it is causing us a lot of problems, since we are in a need of implementation for AJAX.
I haven't worked with Umbraco forms implementations earlier, but I've red that this was basically something out-of-the-box or easily achievable in Contour.
I just want to +1 the need to store Form config and data in the database. We are now running a Load-Balanced environment in Azure where the Umbraco guidance states that the back-office must run on a single install environment. This results in having 2 separate Umbraco installs, sharing a single database. In that scenario the Forms being created/managed by Content Managers are maintained locally to the Back-Office install. Any changes never make it through to the public front-end website. Unless I'm missing something it seems you cannot use Umbraco Forms in an Azure, scaled environment, so database (or some other centralised mechanism) seems the only way forward?
Umbraco Forms or Contour for Umbraco v7?
We are planning to do another round of improvements to Umbraco Forms. We know that many of you are still using Contour on your Umbraco v7 installations, we are very interested to know why you prefer to use Contour instead of Forms.
By getting your answers we'll have a clear idea which features we should focus on adding into the Umbraco Forms product.
I miss the ability to set user permissions in Forms as Contour allows.
I really miss the ablity to copy a form.
Page Id, Page Name and Page URL should be standard fields in the results tables. Or make them options in the on submit section
The Data folder should be in App_Data
Is there any way we can have different versions of the JSON data files? Say for local debugging, staging and production? Something that is detected via VS Debug/Release modes or via the web.config would be awesome!
Reason...I dont want workflows going to live email addresses when debugging locally.
+1 for optional page info and data folder in App_Data.
@martin, reg different versions - see the bottom here: https://github.com/umbraco/UmbracoDocs/blob/master/Getting-Started/Setup/Install/install-umbraco-with-nuget.md
Hi Lars
Hmm, does Forms re-create them at runtime? I thought they were a complete replacement for what was in the database schema? So if they don't get copied, wouldnt you have to manually re-create them in the UI? Or are you suggesting switching them out for versions stored somewhere else?
M.
@Martin, you can still right click the folder and publish if you use VS and web publish. We've got editors working on forms in the production site, so we rather download them for development instead of deploying them from development. :)
The main reason I use Contour rather than Umbraco Forms is that my company has a library that is built against the Contour DLL's that I'm not sure would work against Umbraco Forms (it very well may, but my assumption is that it won't).
Also, I'm hoping to skip Umbraco Forms entirely, as I'm planning to build an open source version (will be starting on that shortly). Details here: https://our.umbraco.org/forum/umbraco-7/developing-umbraco-7-packages/69933-replacing-contour-umbraco-forms-with-something-better
That thread might also be worth reading for some deficiencies in Contour. Perhaps you can rectify them in Umbraco Forms.
I agree with what somebody already said regarding the forms being on the file system. While awesome for source control, it makes doing per-environment changes challenging. One idea that comes to mind would be the ability to enable/disable forms per-environment (i.e., the form would be on the file system, but the toggle would be in the database). I suppose another option would be to gitignore the folder that stores the forms (but then the forms wouldn't be source controlled).
Hi Nicholas
We'd hit the Contour APIs fairly hard and I had to do quite a lot of work to get them running in forms.
Apart from a lack of granular user access, it pretty much does everything we had in Contour. The codefirst methods are a loss, but I dont mind that as the JSON files do the trick nicely.
M.
Personally, I would just like to know what the differences are between Forms and Contour....sometimes I am on a Forms page, next click I am on a Countour page....etc. A simple high level explanation of the differences would be really helpful and would have saved me half a day of building out forms that won't do the job at the end of the day. Would really love to see member update and member create workflows....
For anybody interested in Jamie's recommendation regarding member-related workflows, here's a thread that discusses it in more depth: https://our.umbraco.org/forum/umbraco-pro/contour/72012-umbraco-forms-where-are-the-member-create-and-update-workflows
Hi I've thought of another improvement in view of my question about file deployment...
Can we have a switch in the UmbracoForms.config to change the output files from Json to XML allowing for Forms to read XML as an alternative format.
Reason being, in VS I can then create a template file and instruct studio to transform the necessary parts for debug and release modes upon build and deploy!
This would be an extremely handy feature, plus I still personally feel XML is more readable in situations like this. :-)
Thanks Martin.
+1 to Martins suggestion.
The storage provider should be abstracted and exposed so we can choose json or xml, and possibly also implement our own. (Database for instance)
Great feedback - keep it coming.
We're asking because we're adding new people to the Forms team to make sure it gets up to speed on the features people need for an editor focused Form builder.
Hi Dennis,
I hope that the team is also taking a look at the issues-list on http://issues.umbraco.org/issues/CON. We've created a few issues in the last couple of months, since we've started really using Forms.
Most of them are small issues for better HTML5 and accessibility-compliance (or at least the possibility to do this as a developer).
We've just had an issue where we deployed an update in Azure to a "UAT" slot and then swapped slots to make those changes live. Unfortunately the client had created a new Form in the Production slot and hence when we swapped slots that new form (and any changes to the other forms) were swapped to now be in UAT.
I've had a few issues like this which may have other solutions but it would be good if this type of thing were persisted to the database (which we currently share across both slots), or optional abstracted file system provider in much the same way you can with the Media directory.
For now we're going to have to manually copy the JSON schema files between slots to ensure we have the latest files.
I would also like to suggest this feature: https://our.umbraco.org/forum/umbraco-pro/contour/60788-Umbraco-Forms-and-Ajax
At the moment, it is causing us a lot of problems, since we are in a need of implementation for AJAX.
I haven't worked with Umbraco forms implementations earlier, but I've red that this was basically something out-of-the-box or easily achievable in Contour.
I just want to +1 the need to store Form config and data in the database. We are now running a Load-Balanced environment in Azure where the Umbraco guidance states that the back-office must run on a single install environment. This results in having 2 separate Umbraco installs, sharing a single database. In that scenario the Forms being created/managed by Content Managers are maintained locally to the Back-Office install. Any changes never make it through to the public front-end website. Unless I'm missing something it seems you cannot use Umbraco Forms in an Azure, scaled environment, so database (or some other centralised mechanism) seems the only way forward?
More here: https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/73855-azure-load-balancing-best-practice-with-umbraco-forms
is working on a reply...