If you haven’t yet heard about Supler, it’s a Rapid Form Development library, working with your favorite Javascript frontend and Scala backend frameworks. It keeps the form definition centralized, taking care of client/server-side validation, form rendering, applying new values and serializing/deserializing. Star Supler on GitHub if you think that might be interesting!

But if you are already using Play!, Scalatra, Spring MVC or any other Scala/Java web framework, why would you add Supler to the mix? All web frameworks already provide support for writing, validating and submitting web forms – why not use the built-in tools?

The answer is, as often in software development, it depends. For simple forms like login, register screens, profile edit etc. you should definitely use what your web framework provides. Such forms are usually static, have simple validation rules, don’t have any conditional fields or embedded forms. Also, if the form is central to the user experience of your site you may want to spend the additional time hand-crafting it, providing every possible UX/UI optimisation using custom Javascript.

But then comes the form where you need to conditionally enable/disable fields basing on complex business rules, or dynamically change possible choices in a dropdown, or embed a list of subforms in a form etc., and as most of the fields behave in a standard way, you could use some help from a library. That’s where using Supler will help the most.

You define the form structure on the backend, and only there, in one single place. All conditional logic regarding visibility, enabling fields, validation, dropdown choices etc. can be written having full information about the state of the edited entity, in Scala, using all of its power. Sure, such a setup won’t be optimal when it comes to network communication, and sometimes the validation errors will be visible a couple of milliseconds later as opposed to writing the corresponding Javascript by hand. But working and evolving the form will become much easier and faster. Re-using existing form to embed it to another form? Sure, just define a subform field. Refactoring your entity? The form will be refactored as well, as everything is type-safe. Adding a new field? Just add it to the backend form definition, no changes on the frontend needed.

While Supler imposes some constraints on how your form works, as every library, it is highly customisable, both on the backend and frontend (presentation) side. Take a look at our quick-start guide and extensive documentation.

To sum up:

• for simple, static forms use what your framework provides
• for highly optimized, user-experience-critical forms, hand-craft using Javascript
• for dynamic, complex, nested forms use Supler

Finally, during spring we’ve given a number of talks on Supler of JUGs and a couple of conferences. If you’d like, you can view the shorter one (30 minutes) from Scalar (below) or the long one (60 minutes) from LJC.