Closed Beta: All conversations regarding the beta test group

All topics pertaining to the beta group, please post in this thread.

Open to general public viewing as well.

Cheers

Hi,

I tested mxFormBuilder today and was overall very pleased with it. The manager looks really slick and works well.

Some small things I came across:
In the main mxFormBuilder manager page it says 'Below you can create, edit, disable, and remove contanct forms.', there's a typo in contanct

I'm not a fan of the right clicking in the manager to access other pages, I find it counterintuitive since on the internet right-clicking is hardly ever necessary, and when you do you normally get the browser's right-click menu. But this is something ModX has all over the place so it's not specific to mxFormBuilder.

I tried doing the jQuery validation but it failed since the javascript 'validation.min.js' is loaded at the top of the page, consider making this an option. For speed it is a recommended practise to load on the bottom of the html page and for example Twitter Bootstrap does this too. As I do this, it tried to load 'validation.min.js' before jQuery was loaded and it gave an error.

HTML5 has a bunch of new input types such as email, date etc. (http://www.w3schools.com/html/html5_form_input_types.asp), especially convenient if you're on your mobile (as the keyboard changes to match the input type). Would be cool if they were available.

I really liked the DB saving option and seeing the submitted forms saved on the website. Emails didn't work for me due to, as you mentioned, the ownership field not working when you create a form.

Well that's it for now Good work!

Also had some time to test mxFormBuilder a bit, the following points I noted when playing around with it:

mxFormbuilder Feedback
- I like the independency of mxFormBuilder, does it even work without FormIt? Seems so, but I'm not sure about that.
- Formz reloads the whole manager way to often, mxFormBuilder doesn't do that, great!
- Like the idea of open date and close date, do they publish/unpublish the form completely or just disable submissions (ie set the submit button to disabled)
? Or does the active checkbox do that (make them not submittable)? Edit: Unsetting the active checkbox unpublishes the form completely (so no code is rendered)
- For me personally it would be a nice addition if we could set a field to disable (to display it anyways but deactivate the field) an input
- How does the conditional showing/hiding of fields work?
- Also like the max submissions feature, can not yet see a scenario I'd use it, but it's nice to have that possibility!
- what is the description/instructions field for (maybe additional information/explanation in tooltip should be provided for the fields)
- When selecting a field with mousekey pressed down (drag'n'drop activated), the cursor should change in an up and down arrow symbol to indicate drag'n'drop functionality
- The fine grained customizability of the whole form code via chunks looks much better than in Formz! Very nice!!
- Where/how do I set the email templates? Or is that related to this roadmap item: "Fully managed status options with customized email messages for both owners and the submitter. STATUS: In Development (70% complete)". And just not yet finished? I see the params in the snippet &emailOwnerTpl and &emailUserTpl but wouldnt it be nice if we could edit the email templates in the GUI too somehow? I'm thinking of something like a richttext field for the email Text at the left with the available placeholders (for the actual form) in a column on the right, then the editors could write the mailtext and drag'n'drop the placeholders where they are needed.
- How about sending the data/email to a specific address not assigned to any user (so no ownership)? Like Formz "Recipient" field.
- How to use formbuilder in the frontend (Snippet example), I found [[!mxfb? &formid=`1`]] probably extendable with the params from the snippet
- A TV to select a form would be convenient, could may be done with an @eval and the usage of buildFormList() which is included in mxformbuilder.class.php, from the look and feel it should be similar to the Formz custom TV type.
- It would be nice to have the source (_build / core folders) for making changes and adding stuff (like german lexicon or so)
- Add names and descriptions to system settings (what is mxformbuilder.pa_resource_id used for, for example)
- In Formz there is a possibility to set a custom error message when the reqired checkbox is ticked, but the field is always emtpy...so this would be a nice addition and it would be even nicer if the default error message would be set already (so you don't have to write it manually every time), but could be changed to something else.
- Actually the validation methods in mxFormBuilder are already much nicer than in Formz. Is the custom regex field actually also for validation? If so, this would make the custom error message field even more necessary because a custom regex validation also need to throw a custom error message when validation fails
- In Formz the field placeholder for the email template is shown in the fields grid. I like this but it would be even nicer if we could set custom placeholder names (do they need to be unique? If so every change to a placeholder name would need a db check to see if there's already a field with the same name, this could also be made a little bit more custom in combination with the next point. ie. add custom form ID as prefix to the field placeholder: ID=contact, default placeholder for field1 = contact_field1, and this would be customizable to contact_names or so)
- Formz allows to set a custom ID (identifier) for the form, can be used as class or could be used to generate the placeholders like explained above.
- Formz has different methods for what to do when a submission occurs. Save to db only, save to db and send email. I would like these and also "only send email" and "custom action" (which could be linked to a snippet or so)
- With Formz multiple forms per page (ie multiple snippet calls I guess) seem to be possible (never tried it yet), is this also possible with mxFormBuilder? This is essential for me bc there will actually be several forms per page.

mxFormBuilder Bugs
- Bug: When updating a field and saving it, the before (on creation) set required checkbox is unset and cannot be checked again, so every required field that is updated once cannot be made required again
- Bug: When creating a field and selecting type = text, then below there are fields for min number value / max number value instead of min text length and max text length (this is the right way when you update an existing field, but then the bug above occurs) [ed. note: exside last edited this post 11 years, 2 months ago.]

@nmweb - Thanks for the feedback, agreed on the "right clicking" I've been torn with this in Revo since the beginning. Let me pose the following questions:

1. What events (double-click, single-click, buttons) would make the most intuitive solution for navigating the elements of the form?
   
   
   
   • Update
   • Remove
   • Manage Fields
   • View Submissions
   • Duplicate

Yeah, I've been back and forth on the jQuery position you can find pros/cons for either side of that; the quick fix make an option to select in header or before body close - give you more control.

TO the point of HTML5 form elements there was some thought in that before and can be done now with some quick duplication of chunks and changing the type property to use the placeholder type, thus giving you something like input="email". However that may not be the best solution and will take into strong consideration adding them as specific options with corresponding chunks.

Sorry about the emails, I had a quick change to the variables names and it didn't get carried through to the class file. Fixed and ready for the next beta release.

Cheers

@exside - great feedback and some quick items to highlight from your list quickly.

1. Open/Close Dates and the Active checkbox currently both fully disable the display of the form. In the case of using the Max # Submissions it would display the message if set over the lexicon as the rendered content. The quick fix to the form rendering, but not being able to submit is to disable (uncheck Active) for the submit button field, however can see how the display of form with state of button set to disabled would be an attractive use.

2. How does the conditional showing/hiding of fields work?

   Can you elaborate on this one more, not sure I'm following. If you are referring to the "conditional" option that is a grouping of conditional validation for form fields to be grouped so that at least one of the grouped conditions is true.

3. Formz has different methods for what to do when a submission occurs. Save to db only, save to db and send email. I would like these and also "only send email" and "custom action" (which could be linked to a snippet or so)

   This is stubbed, just haven't turned on yet. Currently its set to use a parameter or property setting to disable form "saves" thus allowing the emails to be sent with all the form data of course.

4. Where/how do I set the email templates?

   See prior note, I messed up a name change on the variables. The two that are used are called emailOwnerTpl and emailUserTpl in the chunks. I'll add more on this in the documentation.

5. - Actually the validation methods in mxFormBuilder are already much nicer than in Formz. Is the custom regex field actually also for validation? If so, this would make the custom error message field even more necessary because a custom regex validation also need to throw a custom error message when validation fails

   Yes, it's another validation option. Ditto on the custom error.

   
   - In Formz the field placeholder for the email template is shown in the fields grid. I like this but it would be even nicer if we could set custom placeholder names (do they need to be unique? If so every change to a placeholder name would need a db check to see if there's already a field with the same name, this could also be made a little bit more custom in combination with the next point. ie. add custom form ID as prefix to the field placeholder: ID=contact, default placeholder for field1 = contact_field1, and this would be customizable to contact_names or so)

   I had this at one time, but took it out - not sure why I did. I'll get that option added back in, why not.

   
   - Formz allows to set a custom ID (identifier) for the form, can be used as class or could be used to generate the placeholders like explained above.

   Again had this at one point, will get this option put back in place. I think the thought was why add more fields that typical users, at least I think, would be makign edits to those. I think there is value in them so I'll get them put back in I just need a clean way to present them so they are not taking up extra space.

Then to a large number of these I'm currently working on the RTFM page with all the documentation on mxFormBuilder, which I hope to have completed tomorrow for a major portion of it, that will help answer a lot of usage questions.

Thanks again for the valuable feedback.

2. ok, I misunderstood this =)...thought there would be the possibility to have inputs that do somehow relate to other inputs that when entered something (maybe even specific) another form section that was hidden before is shown (this would of course involve some frontend javascript stuff and shouldn't be part (or only a little, maybe by adding a specific class to "grouped" elements) of mxFormBuilder I think.

3. very good! Do you actually plan to have a "hook"-like custom action type? Maybe via comma separated list in a system setting like: database, database and email, email, snippetName, snippet2Name and these would be shown in the select dropdown...maybe also a multiselect? so you could just have database, email, snippetName and select any combination of those.

4. See the attached scribble, how about letting users/editors do the emails themselves (at least the content area)...I totally suck at extjs, but I would love to see this because if not available I have to do some work for every form (to set up the emailing) because my editors wont be able to edit chunks...(like the emailTpl chunks)

5. To actually have the placeholders manually editable or just show the automatically generated ones?


I'm actually thinking that maybe separating the extra in two sections, kind of a user section and an admin section (to avoid unnecessary field clutter for editors (and also the possibilities to mess things up =D)) would be a good idea (but makes it also a lot more complicated to develop, probably). something like seen in Big Brother extra where you have an admin Button at the top right for Administrator users (or users of a specific user group).

In such an admin section there could things be set like the id or custom placeholder names or whatever. But I think it should be possible to educate the users about the extra and not having to do this at all...so probably forget about this...there's more important stuff to do =)

keep up the good work!

Ok. Installed fine.

First attempt at the simple form tutorial.

Save just hung, although a page refresh shows the form was in fact saved. Seems to have a problem with the "owner" field, though.

Rather startling when using the context menu to edit the various features of the form. It needs some kind of very clear indication of where I am. Usually updating or editing via a context menu like that brings up a popup/movable overlay rather than a change of page.

@sottwell

Save just hung, although a page refresh shows the form was in fact saved.

Can you check the error log and see if anything is there, not sure whats causing this unless a field didn't get setup correctly.

Rather startling when using the context menu to edit the various features of the form. It needs some kind of very clear indication of where I am. Usually updating or editing via a context menu like that brings up a popup/movable overlay rather than a change of page.

Yes, agreed and I think changing to buttons in the grid row might be more intuitive, but I'm open to suggestions

What events (double-click, single-click, buttons) would make the most intuitive solution for navigating the elements of the form?

Update
Remove
Manage Fields
View Submissions
Duplicate

thanks for your input

Quick update:

List of items coming in the next release either today or tomorrow:

- Custom error message options for each field that is rendered when validation fails
- Ability to set a Form ID property for each form in the form window editor
- Disabling email sends
- Disabling database saves
- Reporting snippet to display and filter form submission information on the front-end


To come a little later:

- Set form submission hooks via the Form editor window vs. using snippet parameters (multi-select) option
- Administrative panel that will provided ability to add, edit, remove any field type and fully manage email templates which then can be assigned in the form editor window.

Cheers


Quick update to the list above to include the reporting snippet. [ed. note: charless last edited this post 11 years, 2 months ago.]

Ah. Creating another one does work; something got tangled up somewhere in the first form I tried to create.

I did have a bunch of "sql error" messages at one point, but was working on something else at the time and didn't connect them in my mind with this. But it was errors relating to getting users, and the "owners" drop-down was misbehaving. As part of what I was working on (the something else - a user signup form) I've deleted all users except my admin user, and it seems to be working fine now. So it may have been something weird about one of the "test" users.

By the way, typo in your CMP heading "Below you can create, edit, disable, and remove contanct forms."