XP Formbuilder app

I have tested it now and it’s very interesting and promising :slight_smile:

However, I feel would be much better simply by removing a lot of things!
Here are some suggestions:

  • Move global settings such as design style to site config, you only need to set this once per site
  • Form: “ID”, action url, submit method and ajax submit?? Users will never understand this - can’t see why you would need them?
  • Form: Title - Can’t display name be used for this purpose?
  • Inputs: Why ID?
  • Inputs: Why repeat name and label (use display name and name from content instead)
  • Inputs: What is the purpose of Title and class? Users will never use or understand this
  • Consider using an HTMLarea for the response text
  • Better naming (i.e. start all content types with Form, maybe use the word “field” over “input” to avoid confusion with XP inner workings too?)
  • Make sure the submitted responses have a nice display name (i.e. form name + first text field in form or similar)

Hope this makes sense?

Hi again, @tsi!

Thanks for your feedback. It is great to see such interest in my project :smile:

TL;DR:
I chose to go for options over pre-made choices, which is why I have enabled so many options. So far I have preferred to use the actual names for attributes, but I will consider making them more user-friendly.
I might fork the project to make a more simplified solution as an alternative, rather than removing options here.

Long version:

  • I agree that moving the design style to site config would be a good idea.
    • On the other hand, I am thinking that you might want to have a specialized styling for certain forms, in which case it would be preferable to just use browser defaults and add your own CSS.
  • Perhaps a solution could be to move the default styling to site config, and have a checkbox to override this in the form?
  • Concerning the other attributes, my idea has been that it should be possible to customize anything (valid) with the forms. As long as it is a legal attribute, I have enabled it.
  • However, I can have a look at whether it is possible to create more default values.
  • @tsi: There was a discussion a while ago about enabling defaults or scripts similar to the Display Name script for other inputs. Is that something that is possible now or will be soon?
  • Regarding action URL, submit method and ajax submit - I have written a bit about that above. I want users of the form to be able to post to their own backend systems, and not only to Enonic.
  • Functionality is included to handle the default case of just posting back to Enonic, but now you can customize this yourself as well.
  • A post vs. get each has it’s use cases, and I don’t see why the user shouldn’t be able to choose…
  • A login form might require the user to move to another page, and as such I wouldn’t want to use ajax, whereas in a contact form, ajax is preferable.
  • I might change naming if you have suggestions, but I do not think I will remove these options. Instead I would prefer to fork the project and make a simplified solution.
  • Regarding input name, I agree that I should probably use the content name. With the title, however, my experience working with editors in CMS is that they often want separate title in the web pages and title of the content, so that should remain separate in my opinion.
  • Input title and class: These are standard attributes for an input element, so why shouldn’t you be able to use them?
  • Using the title attribute for an input field should be mandatory, in my opinion. (But I think I made it optional, just in case)
  • The class attribute is optional, but is there in case the users want to style this particular input field in some special way.
  • I have found this to be a big irritation when customizing third-party forms (or other code), as I wouldn’t have a good way of selecting dynamically generated HTML-tags. Basically I would end up with too specific selectors to be able to reuse the style-rules. Enabling users to add their own classes will help custom styling a lot.
  • Using HTMLarea for response text: I was planning on doing that, but forgot to do this before releasing the code. I’ll change it this weekend.
  • Better naming: I’ll consider a better way to do name them. Not sure about “Form-”, but perhaps an acronym? “XPF-” for “XP Formbuilder”, perhaps?
  • Response display names: Perhaps form name + timestamp? I don’t think I should assume I always would have a text field. (At least I would need a fallback)
1 Like