Software Release Day!

It’s not a terribly common scenario. Mostly, the dataset is pre-defined and static, but sometimes you have no idea what it will look like from one day to the next. This is the scenario I found myself in, recently. So I built a library.

It’s not a terribly common scenario.  Mostly, the dataset is pre-defined and static, and your designer can weave everything together into a thing of beauty and elegance, with absolute control over placement and flow.  Usually, that interface is then solidified, changing only after the design is discarded for something better, and then only in small ways.  But sometimes you have no idea what the dataset will look like from one day to the next, and it’s likely to change and shift regularly.  This is the scenario I found myself in with two completely unrelated projects, recently.

With one, the UI is designed to manage and maintain a complex gateway application, which itself relays incoming requests to myriad third-party services and locations, then presents the results in a unified format.  The settings for each of these third-party data sources include auth data, the exact composition of which is different for every one.  Anywhere from one to four values (in my experience so far) must be presented for a request to go through successfully, and hard-coding these defeats part of the design – we must support multiple sets of credentials for any given data source.  The answer here is a dynamically-generated form, defined by the same parts of the code that allow access to each particular third-party data source.

The other is much less complex.  It consists of what is essentially a survey.  Of course, things are complicated by the fact that the questions will change over time.  This could be handled by changing the underlying code every time – but the client is a non-profit, so the more they can do without having to pay for my time doing it, the better.  So again, the answer is a dynamic form.

But it gets trickier.  The form definition needs to be simple and take up as little space as possible, but it also needs to retain human-readability.  Perhaps the best candidate for this is JSON (JavaScript Object Notation), which most programming languages – not just JavaScript itself – can work with fairly easily.  So where’s the trickiness?  Well, in both cases the backend is forbidden from generating the form itself – for numerous other reasons, both are constrained to speaking JSON.

That means the front-end becomes responsible for the actual construction of the form.  Which in turn means DOM-manipulation.  OK, there are a number of ways to do that, so no huge deal, but there didn’t seem to already be a library to do it automatically – I’d have to implement it directly in the application both times.  And then I’d have to maintain both.  And what if I encountered yet another project that needed such functionality?  I resolved to build a library that could do what I needed, then simply include that library in both applications.

Both applications are built with AngularJS, which has native support for DOM-manipulating libraries in what it calls directives.  Essentially, directives are a way to extend HTML by defining (and then handling) new elements and attributes.  For the validation-paranoid, attributes can be prefixed with x- or data-, which keeps most validators happy.  You can also specify such extended functionality with classes, which sometimes makes more sense if what you’re building is a presentational extension – or your validator is too stupid ancient to allow x- or data- prefixed attributes.

So the natural result of all this is that I built the dynamic forms library as an AngularJS directive.  It is hosted on both GitHub and BitBucket, because GitHub is awesome for getting projects seen and worked on, and BitBucket is what we use at work, so it kind of made sense to put it there, too.  Both repositories have existed for several weeks, but I just now reached the point where the project is releasable, though probably only at a mature alpha or early beta level.  Which is why the release version is tagged as v0.0.0.  I don’t anticipate a large amount of involvement, because thus is such an uncommon use case, but it’s good to mention the release so the project’s visibility goes up (even if only for the search engines…).

Either way, let me know what you think!


Leave a Reply