Drupal is a CMS, right? A vehicle for collecting and presenting information.

There are myriad support for defining different types of content and presenting information, handling layouts, defining access, etc.

And then there are "forms'. There are lots of different solutions for defining forms, mostly aimed at developers.

Now this may sound like a strange question but what are they used for and why are they needed?

To present a front end to developers own modules? To provide an alternate way of collecting content? (much the same thing).

If that's it then fine but in none of the literature I've read is that clear and I get the feeling I'm missing something. There's a lot on 'how' but not a lot on 'why' bespoke are 'Forms needed.

Are they simply a way of bypassing the complexities of Drupal's mechanisms for access control and determining which class of users can see which fields?

This is quite an important point and something which Drupal newbies need to be clear on. If the reality is that 'professional' Druplers simply bypass all of the flexible (and incredibly complicated!) access and presentation services to write their own forms for data collection and presentation because its quicker and simpler (and because they can!), then that's something new site builders really do need to know and should know before they get going, because it will have a major impact on the their projects and the rationale for using Drupal.

So what are bespoke forms for and why are they needed?

Comments

nevets’s picture

Drupal is both a CMS and a framework. So there are many different uses for forms, core and contributed modules provide some standard approaches but they do not cover all the uses for forms one might have.

Jaypan’s picture

To elaborate on nevets answer, Drupal is actually a CMF - a Content Management Framework, rather than a CMS. You can think of it as a Framework that can act like a CMS when you use contributed modules.

The framework itself consists of a whole lot of APIs. An API is basically a method of attaching functionality onto the core framework. One of the APIs is the Form API, which is allows for the creation of secure forms with very little code (as compared to coding forms yourself from scratch). All Drupal forms are built using this Form API. So when you create a content type, the form you use to create that content type is a form that has been created using the Form API. The data is then saved to define the content type, so that when you create a new node of that content type, the Form API is used to generate a form based on the content type settings. The Field API is used for adding new fields to your form, but these fields are just more elements built using the Form API.

This means that any form you see is built using this Form API. Most Drupal developers will never actually touch this API themselves, or at the most, they may override elements of a form in their theme using hook_form_alter(). Some developers who want to build custom forms will use the Webform module, which creates a graphic UI to build forms, but again, these forms are eventually outputted using the Form API. Some developers will choose to create forms that aren't provided by core, in order to create a very specific form to their needs. For example, on Ramenities.com, I built a multi-step ajax form that allows users to enter information on a ramen shop, as well as user information (if they are not signed in), that when submitted creates a new user account in the background, as well as a new Shop Entity, and puts any uploaded images into a moderation queue. This wouldn't be doable with any contributed modules that I know of, which is why I built my own custom form for it.