Jump to content

Should custom forms be built with the ProcessWire Form API?


Recommended Posts

This is something I've been thinking about over the years and I want to hear other people's thoughts on whether custom forms should be built using ProcessWire's form API.

For a simple contact form, I'll usually use Form Builder.

For something like a complicated signup application (like a university admissions application for example), I've used the ProcessWire admin itself (heavily locked down depending on the user's role) as the "form".

However let's take an example of an ecommerce checkout form.

Pros

  • It's the "ProcessWire" way to do it.
  • Built-in server-side form validation, CSRF and session related persistence.

Cons

  • Requires jQuery (for example when showing/hiding) and jQuery UI if using advanced fields (date picker, ASM Select, etc).  Must load the appropriate JS correctly.  You can also argue it loosely depends on Font Awesome 4 for icons.
  • Due to some limitations, it doesn't work well with something like Alpine.js; for example this issue.  Work-arounds are required to get the correct markup in place.
  • It just feels more difficult even though it's the ProcessWire way to do it.

Thoughts?

  • Like 1
Link to comment
Share on other sites

Personally, I prefer the old-school way rather than the ProcessWire way simply because it becomes too cumbersome to use ProcessWire to create Admissions forms, Tax forms, Milspec forms, Aircraft maintenance forms, etc. which I do almost monthly. I did begin with the ProcessWire way and spent way too much time trying to get the layout correct on both the front end and back end, so I stopped using its forms. As you know PHP has some built-in validation such as email, url, dns, etc. The remaining form types are simple enough to validate manually (ie, not using ProcessWire).

Don't get me wrong, ProcessWire is great for the majority of solutions I require and I use it as the base for all current projects. But Ryan built it to satisfy his requirements, which don't necessarily meet with our requirements 100% of the time. When I create complex forms I use css grid and flexbox with custom styles to achieve the necessary front-end layout -- I don't allow user access to any back-end forms. Custom javascript is sometimes required to validate some form elements client side, including ajax calls, but it is nothing major. Also, I don't have to bloat my forms by including one or more third-party javascript libraries.

If I receive a request for a simple form such as a contact form, then yes, I use the ProcessWire way. Otherwise, I find it much simpler to do it the old-school manual way.

  • Like 3
Link to comment
Share on other sites

I build a lot of custom registration forms on ProcessWire sites and prefer to write the HTML directly, with some ProcessWire goodies added on. This seems quickest for authoring forms that match the site and doesn't require jQuery/jQueryUI. I prefer to make forms work even when JS is disabled, if possible.

For CSRF, I manually generate a single-use token and put in the hidden form fields.

I have a custom class that lets me set up a set of fields, their types, and validation rules. Parts of that leverage PW's $sanitizer and sanitized values end up in $input->whitelist() for easy processing and for populating form field values.

  • Like 4
Link to comment
Share on other sites

That's an interesting topic and the reason why I built RockForms. I initially released it open source in 2018 (see forum post), but I've built a new version that is not public yet.

The module tries to solve exactly the pain points that you mentioned @Jonathan Lahijani. It is a wrapper around Nette Forms which is a brilliant library for creating secure and powerful forms. It takes care of all the hard parts when dealing with user input (security, remembering filled fields etc) and it is the only library that I know that let's you write code ONCE and get both client-side and server-side validation rules. By including a small JS file you even get live validation / live feedback with custom error messages. In my opinion that is the best UX you can get.

The drawback of such modules / approaches is always that it get's harder to control the markup of your forms. That's why I have put a lot of effort into making the forms as easily customisable as possible. This is an example that defines custom markup that places two fields into one single row using tailwindcss:

$form->addSelect("salut", "Anrede", [
  'f' => 'Frau',
  'm' => 'Herr',
]);
$form->addText("degree", "Titel");
$form->addMarkup("<div class='md:grid grid-cols-2 md:space-x-6'>{salut}{degree}</div>");

Note that {salut} and {degree} get replaced by full field markup that holds all the necessary form magic (field error, live validation...).

Also it works great with alpinejs and/or uikit because you can easily set custom attributes:

$form->setHtmlAttribute("x-data", "{affiliate:false, azubi:false}");
...
$form->addCheckbox("affiliate", "Ich bin Anschlussmitglied")
  ->setHtmlAttribute("x-model", "affiliate");

You don't need JQuery on your frontend - you can use the tools you want.

And you get forms that fit 100% to the rest of your site. ? 

  • Like 5
Link to comment
Share on other sites

Personally I'm a big fan of Form Builder and there are very few cases where I wouldn't use it. The builder and built-in actions are super flexible, it's often a requirement (or at least preferable) for site admins (content editors) to be able to customize the form, and by adding some hooks one can achieve pretty much anything with it.

As it happens, I've also built a few e-commerce checkout forms with it, and would definitely do it again ?‍♂️

Cases where I usually go with a custom form are one-off cases with heavy focus on accessibility, super specific layout requirements, mostly custom inputs (which are of course possible to handle with Form Builder, but not exactly straightforward), or loads of custom JavaScript logic.

I'll admit that this is quite opinionated, but I've never found the API way of generating forms particularly useful: for me at least markup is both easier and faster to generate without it (particularly if there are specific requirements), validation is in most cases a relatively minor issue — unless it's a very complex setup, in which case there are brilliant third party tools available — and core features such as $session->CSRF->renderInput() and $session->CSRF->hasValidToken() work just fine without it.

Long story short: it's either Form Builder or custom form implementation for me ?

  • Like 6
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...