Orchard 1.9 Dynamic Forms feature team

Topics: Announcements
Developer
Oct 15, 2014 at 1:12 AM
This thread is to discuss the Dynamic Forms feature for Orchard 1.9.

The purpose of the Dynamic Forms module is to provide a visual designer where the user can design forms to be displayed on the front end. It is built using the Layouts module.

In a nutshell
  • Forms are composed of Elements.
  • Elements can be moved around the designer surface in drag & drop fashion (inherited from the Layouts feature).
  • Forms can be configured to store submissions as records (non-content items) and/or as content items using a mechanism called Binding. Each content part and field can provide their own binding operation to match input against properties on a part or field.
  • Supports Workflows by triggering a workflow event and corresponding FormSubmitted event activity.
Developer
Oct 15, 2014 at 1:15 AM
The current list of available elements looks like this:
  • Button
  • Check Box
  • Enumeration
  • Form
  • Hidden Field
  • Label
  • Radio Button
  • Text Area
  • Text Field
  • Validation Message
  • Validation Summary
Question: what additional elements do you think should be provided by default?
Please give the module a spin and let us know what you think.
Oct 15, 2014 at 5:11 AM
Please provide a "PASSWORD TEXT BOX" for Orchard 1.9
Oct 15, 2014 at 12:36 PM
I would really love to see file inputs, that don't require the MediaLibrary (specific for the frontend users).

Options:
  1. Allowed extensions
  2. Maximum number of files (1 - x)
  3. Preview file(s)
Coordinator
Oct 15, 2014 at 7:10 PM
Edited Oct 15, 2014 at 7:10 PM
Everything needs to be themable from the front end theme. So that themes can improve how the forms look like, even single elements like file uploads.

For that we might need to use TagBuilder and Shape morphing extensively.
Developer
Oct 15, 2014 at 10:46 PM
Yep. Every element has its own shape template, which by default is implemented using a TagBuilder. Customizing each individual element should be simple.
Developer
Oct 16, 2014 at 3:16 AM
Edited Oct 16, 2014 at 3:18 AM
sanderg wrote:
I would really love to see file inputs, that don't require the MediaLibrary (specific for the frontend users).

Options:
  1. Allowed extensions
  2. Maximum number of files (1 - x)
  3. Preview file(s)
I propose we implement a FileUpload element with the following characteristics out of the box:
  • Configure the allowed extensions.
  • Configure the maximum allowed file size.
  • Configure the number of file inputs to generate (deaults to 1). If the theme uses some sort of AJAX / Flash file upload mechanism, this setting could be used as the maximum number of files to upload. The maximum upload size is per file.
  • No option to preview selected files - this is a theming concern. I think the default behavior of such a feature would be too simplistic to be actually useful.
  • An option to save the uploaded file. The user can configure the destination folder.
  • An option to create a Media Item for the uploaded file so that it becomes available in the Media Library.
  • If the file was turned into a media item, the submission provides links to each created media item. Otherwise it provides a direct link to the physically stored file.
  • An option to save the file using a specified format (tokenized).
  • An option to a) overwrite existing files, b) generate a new filename, or c) reject the upload in case a file with the (uploaded or generated) filename already exists.
  • To be investigated, but the uploaded file stream would be made available to the workflow engine, so that custom activities can do something useful with the files, without having to actually store the files.
Developer
Oct 16, 2014 at 9:01 AM
AkashLalDas wrote:
Please provide a "PASSWORD TEXT BOX" for Orchard 1.9
Password Field has been added.
Oct 16, 2014 at 7:27 PM
Hi,
  1. On the computers screen resolution (2080x800 px), missing link, "Add Element" for the form.
  2. Why you have not used the field from the Orchard.Fields module, as implemented in the Orchard.CustomForms module? It is, in principle, not possible, or you intend to migrate form elements in the Orchard.Fields module?
Thanks
Oct 17, 2014 at 1:33 AM
Took a brief look at the code - very exciting stuff here!

I have a few ideas, and wanted to see if they are appropriate for this module and gauge the level of effort:
  1. Element groups - a collection of an arbitrary number of other elements. A simple example is to group "Billing" and "Shipping" contact info separately. Rather than having text elements like "BillingFirstName" and "ShippingFirstName" you might have a "Shipping" group with "FirstName" "LastName" etc. Groups might have a name, and the collection of sub-elements.
  2. "Repeatable" setting for various (any?) elements - an example is a form that allows users to input a list of their favorite songs. One user may have 5 favorite songs, another has 10, another has only 1, etc. Various elements could specify a "min" and "max" (including unbounded) number of times they can be entered. The form designer places a single text field in the form, but the user can repeat it up to "max" times.
Let me know what you think.
Developer
Oct 17, 2014 at 2:19 AM
Edited Oct 17, 2014 at 2:20 AM
Vite wrote:
Hi,
  1. On the computers screen resolution (2080x800 px), missing link, "Add Element" for the form.
I don't know how to simulate that kind of resolution. If you decrease the browser window to below 2080x800, does the missing link suddenly appear? Can you do some tests and let us know? Thanks.
  1. Why you have not used the field from the Orchard.Fields module, as implemented in the Orchard.CustomForms module? It is, in principle, not possible, or you intend to migrate form elements in the Orchard.Fields module?
Orchard.Fields implements form fields as ContentFields. Orchard.Layouts elements aren't content fields; they are an entirely different thing. However, the goal of Orchard.DynamicForms is to have feature parity with Orchard.CustomForms, plus much more.
Developer
Oct 17, 2014 at 2:28 AM
Edited Oct 17, 2014 at 2:29 AM
thekaveman wrote:
  1. Element groups - a collection of an arbitrary number of other elements. A simple example is to group "Billing" and "Shipping" contact info separately. Rather than having text elements like "BillingFirstName" and "ShippingFirstName" you might have a "Shipping" group with "FirstName" "LastName" etc. Groups might have a name, and the collection of sub-elements.
I love the idea! Actually I considered something similar when we started the Element Blueprints feature, where each blueprint would be a layout in itself.
What you can do right now is create an element based on the Grid element, and add the various fields.
What we would have to do next is come with a way where you can now configure some settings when you actually drop this composite element onto the canvas so you can name the element (e.g. "Shipping Address" and "Billing Address"). We'll give it some more thought.
  1. "Repeatable" setting for various (any?) elements - an example is a form that allows users to input a list of their favorite songs. One user may have 5 favorite songs, another has 10, another has only 1, etc. Various elements could specify a "min" and "max" (including unbounded) number of times they can be entered. The form designer places a single text field in the form, but the user can repeat it up to "max" times.
This sounds interesting, but I wonder how often this would be used. You could implement this using a custom module, implement an element handler, and provide the additional Repeatable setting and behavior.

Thanks for the suggestions!
Developer
Oct 17, 2014 at 2:32 AM
sfmskywalker wrote:
What you can do right now is create an element based on the Grid element, and add the various fields.
Scratch that, that won't work right now, since the Grid does not expose an editor to edit its child elements - the layout editor handles this.
Oct 17, 2014 at 4:55 AM
I think the real power of "Repeatable" like behavior would come from applying it to more complex elements. You could almost look at "Repeatable" as a generalization of:
I propose we implement a FileUpload element with the following characteristics out of the box:
...
Configure the number of file inputs to generate (deaults to 1)...this setting could be used as the maximum number of files to upload.
In the case of the FileUpload element, it could define the behavior around how many files a user may upload. Anyway, I haven't given it that much thought. I'll see if I can come up with something more concrete in the next few days.
Oct 19, 2014 at 11:20 PM
sfmskywalker wrote:
I don't know how to simulate that kind of resolution. If you decrease the browser window to below 2080x800, does the missing link suddenly appear? Can you do some tests and let us know? Thanks.
I changed the value of min-width, and it feels good
File (layout-designer.css)
body {
  ...
  min-width:100%; /* 946px */
  ...
}
Oct 19, 2014 at 11:50 PM
Edited Oct 19, 2014 at 11:56 PM
  1. If you attach the token {User.Name} for the field "Show Notification", then at the front end displays the text "{User.Name}".
  2. You want to implement a function to send the form to the specified Email?
Oct 22, 2014 at 8:33 AM
Mate,

What about some dynamic cascading dropdownlists with partial views? Ouch.

PK :)
Developer
Oct 22, 2014 at 9:55 AM
I'd say: go for it! :)
Oct 25, 2014 at 12:25 PM
thekaveman wrote:
I have a few ideas, and wanted to see if they are appropriate for this module and gauge the level of effort:
  1. Element groups - a collection of an arbitrary number of other elements. A simple example is to group "Billing" and "Shipping" contact info separately. Rather than having text elements like "BillingFirstName" and "ShippingFirstName" you might have a "Shipping" group with "FirstName" "LastName" etc. Groups might have a name, and the collection of sub-elements.
I would add to that the ability to have tabbed interfaces and nest fields in each tab.
Developer
Oct 30, 2014 at 11:03 PM
Vite wrote:
  1. If you attach the token {User.Name} for the field "Show Notification", then at the front end displays the text "{User.Name}".
    Good catch. It is fixed.
  2. You want to implement a function to send the form to the specified Email?
No need to; simply setup a workflow using the "Dynamic Form Submitted" activity and the "Send Email" activity, which you configure to send an email to the specified Email field using the FormSubmission.Field token.

For example, if you have a form with two text fields: "Name" and "Email", you would use the following tokens to access these values when a form is submitted:
Email Addresses: {FormSubmission.Field:Email}
Subject: Hi, {FormSubmission.Field:Name}!
Oct 31, 2014 at 12:29 PM
@Sipke I have updated the application of last modified branches 1. x, but I still get the text "{User.Name}" for the field "Show Notification". I created a new database, the result is the same. I noticed that the tokens work well for validation.

Thanks
Developer
Nov 1, 2014 at 3:57 AM
Hmm. Can you provide me with some screenshots, or even better: a screencast? Or hit me up on Skype so you can show me: sfmskywalker.
Nov 1, 2014 at 9:07 AM
Is the example snippet correct ? :
Email Addresses: {FormSubmission.Field:Email}
or should it be :
Email Addresses: {FormSubmission.Field.Email} 
(dot instead of semicolon before Email)
Developer
Nov 1, 2014 at 9:19 AM
Edited Nov 1, 2014 at 9:21 AM
The first example snippet is correct (with the semicolon).

To elaborate on the reasoning: the first portion is the token syntax (ContextName.TokenName).
The second portion is the parameterization if you will (:param).
I figured it makes sense to distinguish between the two, but I'd be happy to hear other arguments in favor of dot notation all the way.
Developer
Nov 3, 2014 at 12:31 AM
Vite wrote:
@Sipke I have updated the application of last modified branches 1. x, but I still get the text "{User.Name}" for the field "Show Notification". I created a new database, the result is the same. I noticed that the tokens work well for validation.
This is fixed now. Thanks for testing.
Nov 18, 2014 at 9:37 PM
A feature that would be really great is a way to do a hook before and after the three Form Events (Submitted, Validating, Validated). I have no idea how this would be implemented at this point but it is just a feature we had on our Drupal site which we are converting to Orchard.

Here is the scenario. We have a donation form that uses the Authorize.net AIM API to process credit card payment. Obviously we do not want to store credit card info so it would be great if after everything is validated we can send the payment info to Authorize.net and then clear the credit card info fields before they are stored in the database. We can write our own field elements for credit card info which would clear out the value before submission, but then there does not appear to be a way to submit the values to authorize.net.

Right now I see no way to implement this with Dynamic Forms which is a real bummer as we would have to re-implement a lot of it's features in our own module rather than just extending it.
Developer
Nov 20, 2014 at 7:10 AM
Edited Nov 20, 2014 at 7:10 AM
Could you achieve what you want if we added a Submitted event?
So the events would go like:
  1. Submitting
  2. Validating
  3. Validated --> You invoke the Authorize.NET AIM API here.
  4. Submitted --> You clear the credit card field here.
Nov 20, 2014 at 1:07 PM
That would probably work as long as Validated does not have the ability to submit the values to the database as if that form setting is set then the field would hit the database and then have to be cleared. We are trying to avoid that if at all possible. The issue I see with that is that we would need to override Validated for all forms (unless we want to check for a certain form name or something similar, or write our own form element that we can check for) which we definitely do not want to do as any core changes to the Validated function would have to be rewritten in our override.

What we decided to do is create a new module with a payment form controller. The controller then calls a new payment form service which then lets us call any events in whatever order we need. This seems like a much better way to handle this as then all we need to do is change our post url in the form settings to our controller for forms that are for payments. We can then leave all the core alone, so non-payment forms just use the core.
Dec 6, 2014 at 9:12 PM
Edited Dec 6, 2014 at 9:14 PM
I know that this is still being worked on, but after playing with Dynamic Forms in a real scenario here are a few issues/bugs that were found in case you are not aware of them yet. I can create work items for any of them if you would like me to as well.
  • On form submit, even if there is a model error it still goes to the redirect url rather than back to the form to show the error
    Maybe just need to do something like this in the FormController Submit action?:
Change
var redirectUrl = !String.IsNullOrWhiteSpace(form.RedirectUrl) ? form.RedirectUrl : urlReferrer;
to something like
var redirectUrl = !String.IsNullOrWhiteSpace(form.RedirectUrl) && ModelState.IsValid ? form.RedirectUrl : urlReferrer;
  • Validation summary is not per form. If you have multiple dynamic forms on a page and validation summaries for each form, both will show errors from the other form. For instance, on our contact us page we have a contact us dynamic form and then in the footer we have a dynamic form widget to sign up for our newsletter. Both have a validation summary that should be separate, but if there is a validation error on one it shows in both summaries even if the other form does not have the same field name.
  • Dynamic Form Validating workflow activity has no way to add scripting yet. This is a new feature so I am guessing you just haven't had a chance to get this working yet. I see there is some code for it, but the field is never rendered.
  • Decision workflow item does not appear to have access to FormSubmission.Field values. This is probably because you are planning on using the Form Validating workflow, but wanted to give the heads up that the token is there, but does not seem to be working.
  • No option to add required validation on enumeration form fields. It would be nice if we can force users to select an item in an enumeration form field.
  • No way to stop double submits. This would be a nice to have option on button elements but understand if it doesn't make sense to be in the core. I currently implemented it by just having our users add a class to the button and then a script looks for the class and stops the double submit.
  • No Regex validation on normal text fields, only passwords. This would be really handy to have.
Thanks Sipke for your work on this! Let me know if you need anything.
Dec 7, 2014 at 12:10 AM
Edited Dec 7, 2014 at 12:43 AM
I have not used yet dynamic forms, but after reading this discussion
  • Would be great for file inputs
  • And also for stream available to the workflow
One simple scenario, which would use these 2 features, is the ability to upload a file(s) on submission, and send an email with this file attached
Submit => File upload => File stream => Workflow => Email activity with file attachment

Currently, I have to implement it with others Orchard extensibility

Thanks for your work
Developer
Dec 8, 2014 at 1:51 PM
@PacmanDave Thanks for the feedback, this is great. We'll look into each item. Some quick feedback and questions on some of them:
  • Dynamic Form Validating activity has no way to add scripting yet: this is correct - it will be enhanced with scripting support. Work has been started, but is not yet done.
  • Decision workflow item does not appear to have access to FormSubmission.Field values - I could not reproduce this issue, it works fine when I try. If you want you can open an issue for this with repro steps.
Thanks again, this is very valuable.
Developer
Dec 8, 2014 at 2:42 PM
@jtkech

Thank you for your suggestions.
We have decided that we won't be providing file upload elements out of the box (for now at least), but we'll provide a contrib module with this functionality, which may serve as an example and be customized to one's particular needs.
Dec 9, 2014 at 9:52 PM
sfmskywalker wrote:
  • Decision workflow item does not appear to have access to FormSubmission.Field values - I could not reproduce this issue, it works fine when I try. If you want you can open an issue for this with repro steps.
This is probably just a syntax issue on my part then. In the log I just get Object reference not set to an instance of an object.

This is the script I was using. first_name is the name of a field in the form:
if ("{FormSubmission.Field:first_name}" == "test") { 
  SetOutcome("true");  
}
else {
  SetOutcome("false"); 
}
Dec 30, 2014 at 6:06 AM
@PacmanDave, maybe related to this ticket on OrchardPros http://www.orchardpros.net/tickets/4728

See my answer, quickly tested. I have seen that the decision activity need a content item. So, in your form settings you have to check the "Create content" on submission and associate it with a content type that you have created...

If you don't want to create a content item, a workaround is to test if the content item is null in DecisionActvity.cs before using it (see the ticket)

Just try your script, with the workaround and without creating a content item on submission. To get it work, I have to replace
"{FormSubmission.Field:first_name}" with "#{FormSubmission.Field:first_name}"

Regards
Feb 12, 2015 at 12:43 PM
Edited Feb 12, 2015 at 1:27 PM
I create a new dynamic form, add some text fields to it.
I edit a field, check "Show Label".

Whenever I type a string with spaces in it, the text I typed appears both in the editor and in display modes with plus signs (+) where spaces should have appeared. I.e.,

"User Name"
appears as
"User+Name"

Bug? Feature?

(Plus signs are being html encoded... grr...)
Developer
Feb 12, 2015 at 1:51 PM
That's a bug that has been fixed in the feature/layouteditor branch (soon to be merged back into 1.x).
Developer
Feb 12, 2015 at 3:24 PM
I tested the layout editor and the dynamic forms features.
I think I will create some issues to report a few bugs I encountered and suggest some enhancements.
May be we could add a new 'Component' for this or a new branch in the issues.

I tried to create a theme from a Bootstrap template I had to integrate.
I had some annoying behaviors using the layout editor, specially with HTML.

Concerning TinyMce, the integration in 1.x doesn't seem as well adapted to Orchard as the previous one (ex : source code in full screen is missing).
I couldn't paste a large and quiet complex html code in Source mode, it was partially 'swallowed' (some content trimmed and reencoded) when I published.

I agree this is a huge enhancement for people that doesn't really know Html but if we lose some flexibility and cannot edit all the contents in Source mode, it wouldn't be a progress.
Just the fact to replace the BodyPart by the LayoutPart is impactful from my point of view.
Developer
Feb 12, 2015 at 4:51 PM
Edited Feb 12, 2015 at 4:52 PM
Thanks for testing Antoine.
Did you test 1.x or feature/layouteditor?

Obviously we do not intend to limit flexibility in any way, so please do file an issue demonstrating the issues that you found.

Changing out the BodyPart with the LayoutPart is absolutely impactful, but we sure as hell hope in a positive way. If you think otherwise, then please elaborate on specific issues so we can see if we can make further improvements.

Thanks again for taking the time to do this, it's greatly appreciated.
Feb 14, 2015 at 1:06 AM
@Sipke, just for infos because I just tried the last feature/layouteditor branch

With some form values that contain some commas (e.g the body of a text element), the value is broken on the first comma encountered

A value can be url decoded without have been encoded. E.g if you want to display an url encoding code, you will display the encoded character itself

See my last answer on this ticket: http://www.orchardpros.net/tickets/4821

Otherwise, great work, thanks
Developer
Feb 15, 2015 at 8:26 AM
agriffard wrote:
I tried to create a theme from a Bootstrap template I had to integrate.
I had some annoying behaviors using the layout editor, specially with HTML.
Can you elaborate?

agriffard wrote:
Concerning TinyMce, the integration in 1.x doesn't seem as well adapted to Orchard as the previous one (ex : source code in full screen is missing).
This is the same way for the BodyPart, so this seems to be unrelated to Layouts itself. Can you confirm?

agriffard wrote:
I couldn't paste a large and quiet complex html code in Source mode, it was partially 'swallowed' (some content trimmed and reencoded) when I published.
This should be fixed now in the feature/layouteditor branch. Please let me know if you are still having problems pasting in your HTML code. If you do, would you mind providing me with a copy of that?

Thanks
Developer
Feb 15, 2015 at 11:23 AM
It took me a moment to understand how to make it work with Bootstrap and if it was well adapted.

As you say, the TinyMce oddities I found are not related to the Layout Editor, I will put then in a separate discussion and issue (Toolbar, Full screen, ...).

I will also dig more into the Dynamic Form and make some suggestions. It will be really helpful and powerful.

It seems you corrected the error I had, pasting HTML (may be with ',' as jtktech noted). It was only occuring with the TinyMce in 'Dialog' mode, not in 'Inline' editing.

The more I use it, the more I like it so it seems to be the good direction. Keep on enhancing the usability.

Here are a few things to check:
One random strange behavior is that the layout part isn't loaded when I create or edit a page (and no error in javascript console). If I hit F5, it loads.ortcut
If I want to edit the css class, the shortcut 'space' is not well chosen becaus I can't add 2 classes spearated by a space.
If I enable the Localization/Culture feature I have an error loading some dialog boxes (HTML, may be Content also, I have to retest)
Mar 19, 2015 at 11:56 PM
sfmskywalker wrote:
thekaveman wrote:
  1. Element groups - a collection of an arbitrary number of other elements. A simple example is to group "Billing" and "Shipping" contact info separately. Rather than having text elements like "BillingFirstName" and "ShippingFirstName" you might have a "Shipping" group with "FirstName" "LastName" etc. Groups might have a name, and the collection of sub-elements.
I love the idea! Actually I considered something similar when we started the Element Blueprints feature, where each blueprint would be a layout in itself.
What you can do right now is create an element based on the Grid element, and add the various fields.
What we would have to do next is come with a way where you can now configure some settings when you actually drop this composite element onto the canvas so you can name the element (e.g. "Shipping Address" and "Billing Address"). We'll give it some more thought.
  1. "Repeatable" setting for various (any?) elements - an example is a form that allows users to input a list of their favorite songs. One user may have 5 favorite songs, another has 10, another has only 1, etc. Various elements could specify a "min" and "max" (including unbounded) number of times they can be entered. The form designer places a single text field in the form, but the user can repeat it up to "max" times.
This sounds interesting, but I wonder how often this would be used. You could implement this using a custom module, implement an element handler, and provide the additional Repeatable setting and behavior.

Thanks for the suggestions!
@sfmskywalker, I'm wondering if you or @Decorum can provide any guidance, even at a high-level, as to how to I might approach this. Is it a matter of providing an implementation of Orchard.Layouts.Services.IElementEventHandler and hooking in to the BuildEditor/UpdateEditor events to provide repeatability to certain field elements? I've spent a few days trying to dig into the details of Layouts and Dynamic Forms - particularly how field elements are implemented - and it hasn't all quite "clicked" yet.

I'm at a point where a repeatable setting would be extremely useful; especially when trying to convert an existing paper-based form/workflow into an electronic form/workflow. Consider an application process (e.g. for some kind of permit or license) that asks for the applicant's criminal record (I am working to convert such a paper application into a Dynamic Form at the moment). One applicant may have 0 arrests. Another applicant may have 1 arrest. Another applicant may have N arrests...
On the paper form you can simply say If you need more room, please attach a separate sheet. This doesn't work in an electronic form. It would be great to be able to have a way to set the repeatability of a field - the field's value then becomes an array of values, rather than a single string (for example).

This really goes hand-in-hand with my other suggestion of a "Compound Field" / "Element Group" type of field. And to be completely honest, I stole both ideas from our legacy CMS software (closed-source, unfortunately) that I'm working to migrate off. The forms/types designer in that system allows you to group related fields under a common container. Any other field type, including containers, can be included in this grouping. The container can then be configured to allow a user of the form to enter 0, 1, or many instances of the group. Allows for some pretty awesome and complex forms, with a nice hierarchical data structure in the backend.

I would go so far as saying it would probably be enough to give the "Compound Field" the repeatability behavior, since anything else contained in it would then also repeat. But alas, it seems I have barely scratched the custom-layout-elements surface and I am having a hard time figuring out where to start :-)

Thoughts?
Mar 20, 2015 at 8:39 AM
@thekaveman,
About the repeatable feature,
What you describe while very useful requires thinking about binding issues with the data side.
In the above example with the Applicant-- arrests example basically you are describing a 1-m relationship at the data level.
But how is this data modeled?
Is the many side of the relationship stored as one document in the infoset or is each arrest a record in a separate table ?
This reminds me of the forms - subforms feature you can see in Microsoft access database.
Where basically you have two separate forms - a main form and a subform (which is set as repeatable) and through metadata is linked to the main form.
So at the subform level you would define the binding stuff and how it is linked to the main form (through which fields).