blogarchive

Sure, a form collects data, it might actually be doing some cool things behind the scenes like sending email and storing the results in a way that lets you browse through them, but make no mistake, a form is not an application, it is just a form.

  • Aug 28, 2018
  • Grant Shepert
  • Developers
  • Development

I'm going to stop you right there. It is this question where most people get into trouble, because the answer is always the same—never.

Sure, a form collects data, and it might actually be doing some cool things behind the scenes, like sending email and storing the results in a way that lets you browse through them, but make no mistake, a form is not an application, it is just a form. What the form does on the other side is the application, and usually that's already been designed towards a very specific set of functionalities.

This article is intended to prevent you from making a simple, but grievous mistake. There are many ways to collect data with Mura, and many specific ways to use that data. The trick is understanding the differences and limitations of each, and making informed decisions so that you don't waste any development cycles.

Mura forms & FormBuilder

If you've built a form in Mura, you have most likely done this in one of two ways, using the old-school (and yes, a bit kludgey) CKEditor form tools, or the much more user-friendly FormBuilder Module.

Either way, you might be surprised to learn that both of these tools essentially do the same thing, and have only one role—creating a form. The FormBuilder may be a lot fancier – it lets you build out custom drop-downs and include custom actions – but essentially, the two options produce the exact same thing, a form for the front-end, customer-facing side of your website.

Forms are not an "application," they are simply a method of capture and storage. Try to do anything fancier with the data, and you are likely to run into trouble quickly.

The handling of these two types of forms, submission-wise, is also exactly the same. Both send forms to the same set of processing functions where results are variously archived inside your Mura database, and possibly emailed to one or more addresses.

As far as data tools are concerned, it is fairly limited by design. There is a simple administrative interface with options for browsing, deleting or downloading submitted data, but that's about it.

Because form submissions aren't stored as normalized data, they are terrible to use as the basis of an application.

One of the key things to remember here is that all forms built using either of these tools are intended for only one purpose — to capture the information a user enters into the form. They are not an "application", they are simply a method of capture and storage. Try to do anything fancier with the data, and you are likely to run into trouble quickly.

The form data

Form submissions are stored as compact, archived records, not as true data.

There are two very important features in a Mura Form. First, a form can collect a wide variety of data formats, via drop downs or text fields, radio or select boxes, in any number of fields from a few to possibly hundreds (though I'd highly recommend against it). Second, forms can change. It is possible to add or remove fields at any time, even if the form has already been used to collect data.

Because of this variable nature, submitted form data is stored in what is essentially a flat, non-normalized data block. This means it isn't very friendly for searching, there are no spreadsheet-style tables that organize it, and it isn't well-optimized for use as "data".

Aha!

Because form submissions aren't stored as normalized data, they are terrible to use as the basis of an application. Even though it feels like you can get things 90% set up the way you want, it's that last 10% that will kill you.

Solutions

If it sounds like what I'm saying is that forms make for terrible applications, then we have arrived at an understanding.

The next step is to consider your options. Thankfully, there are many.

Plugins

I'm not going to dive into the lengthy topic of Plugin development here, however, there is thorough documentation available which explains how to integrate your custom applications, whether simple or immensely complex, into the Mura Platform.

In most cases, the only time you would choose a Plugin over a Module for your Mura customizations is if you want to include administrator-only functionality (i.e. settings, reports or other application UI directly inside the Mura admin area). Otherwise, you will likely find that a Module can contain all of the interconnectivity and tools you will require.

We have several Plugin tutorials listed at the bottom of the page, but the Plugin starter projects from Steve Withington, both his vanilla no-framework and more powerful FW/1 examples, are a great place to start.

Scaffold that data!

For applications of more modest means, Mura 7.1 includes a new tool that makes life much easier. It is, in fact, a pair of applications, called "Scaffolder" and "Assembler".

The Mura Scaffolder takes the information you've entered into the Mura Assembler and turns these data objects into usable forms.

Assembler is the self-describing name for our application that lets you design a complex data object – for example, a directory of store locations, a library of song titles, or a staff listing. You can assign custom indexing to fields, define data types, mark them as required, and even link multiple assembled objects together (e.g., tying your store locations to your staff directory).

The Mura Scaffolder takes the information you've entered into the Mura Assembler and turns these data objects into usable forms. You can browse, sort and filter records, add and delete, essentially utilizing the entire CRUD family of functionality directly through the Mura admin interface.

There is one catch here, though. These forms are strictly on the back-end, not publicly available, and there is no feature in place to automatically show these admin views as front end "forms". To put your applications on the front-end, you need to take into consideration a host of questions:

  • Who will have access?

  • Am I putting up only the form, only the submitted form results, or both?

  • Is there a moderation system required before submitted results are displayed?

  • When I display the results, will they be paged, sorted and filtered?

This is where the "application" bit becomes important because every implementation is likely to be a little different.

Hello, front-end user

Assuming your goal is to take user input, there are a couple of steps you can take.

Secure that form

First, you will likely want to access-protect the page that the form resides on.

For general use forms such as "contact us" email messaging, this isn't usually required, but for an application-type form it is almost always a good idea. If you aren't going to protect your form, you will need to pay close attention to the type and source of data being entered, and will almost certainly want to moderate the content before it is ever displayed anywhere. This is simply good operational security at work. You can either use the Mura Scaffolder on the back-end, or architect something custom to your needs (likely in a Plugin).

Render that form …er, application interface

This is the better way to think of your form now … as a user interface to your application. Since you are thinking about putting this on the front page, you may need a Plugin, but it is likely you can achieve this much more easily with a custom Module (formerly known as a Mura "display object"). Again, building a custom Module is beyond the scope of this presentation, but luckily we have several examples that you can draw from (see below).

Form vs Application

So, what have we learned today?

First, and most important, is that Mura Forms are not the starting point for your custom application. They are an application unto themselves, and extending them would be a lot of unneeded work which could be better applied to something built just for the purpose at hand.

Second, the Mura 7.1 Assembler & Scaffolder are your friends and could eliminate a ton (maybe all) of the work you need to do to get your custom data entered inside of Mura.

Finally, that there are multiple options in taking that data and displaying it on the front of your website.

Hopefully, the examples and resources referenced below will give you everything you need to get started. If not, hit us up on the Mura Slack channel or Google group and we'll see if we can't find you a solution.

Additional resources

Intro To Mura 7 Display Objects (video):
getmura.com/blog/video-intro-to-mura-7-display-objects-muracon-2017

Mura & Vue JS: A Love Story:
getmura.com/blog/webinar-mura-and-vue-js-a-love-story

No-Framework Plugin starter: 
github.com/stevewithington/MuraPlugin

Mura FW/1 Plugin starter: 
github.com/stevewithington/MuraFW1

Scaffolder & Assembler:
docs.getmura.com/v7-1/mura-developers/.../mura-orm-assembler-scaffolder/

CFML/Mura Slack channel: 
cfml.slack.com/messages/C0FBLG0BF

Mura Google Group:
groups.google.com/forum/#!forum/mura-cms-developers

 

 

 

Developers

Blog Post
By Grant Shepert
Blog Post
By Grant Shepert
Blog Post
By Grant Shepert
Blog Post
By Grant Shepert
Blog Post
By Grant Shepert
Blog Post
By Grant Shepert
Blog Post
By Grant Shepert
Blog Post
By Michael Evangelista
Blog Post
By Grant Shepert
Blog Post
By Grant Shepert
Blog Post
By Michael Evangelista
Blog Post
By Michael Evangelista
Blog Post
By Grant Shepert
Blog Post
By Matt Levine
Blog Post
By The Mura Team
Blog Post
By Pat Santora
Blog Post
By Pat Santora
Blog Post
By Matt Levine
Blog Post
By Matt Levine
Blog Post
By Matt Levine
Blog Post
By Eddie Ballisty
Blog Post
By Sean Schroeder
Blog Post
By Grant Shepert
Blog Post
By Grant Shepert
Blog Post
By Grant Shepert
Blog Post
By Grant Shepert

Marketers

Blog Post
By Andrew Medal
Blog Post
Blog Post
By Ronnie Duke
Blog Post
By Sean Schroeder