dispatch icon indicating copy to clipboard operation
dispatch copied to clipboard

Severe feature-creep in Dispatch "Templates"

Open keeganland opened this issue 3 years ago • 0 comments

This issue is somewhat "high level" and vague, but captures what I believe to be many issues with the Dispatch project.

The Dispatch Templates tab lacks a design contract, and lacks a relationship with what it was intended to be a selector tool for - namely, Django Templates. This drift has occurred over the lifespan of Dispatch like follows:

  1. Since a Django View renders a Django Template based on a string of an HTML filename and some context variables, someone realized you could set which Django Template to be used with user-entered values at a certain point in the Model/View part of program lifecycle. In order to restrict what the users can do with this idea though, a dropdown is implemented that correspond to particular filenames. This was the original core of the Template tab: select a Django template.
  2. But then editors started to request different page layouts they could select from that did not necessarily contain the exact same data. This should technically be interpreted as a request that the Model be altered. But because there were conflicting such requests, a "flexible" solution was sought. The developer added a "template_data" field to contain JSON that would contain flexible extra "field" values over and beyond what was in the table. Kind of sketchy way to do it. Different possible "fields" for template data appear for data entry depending on the dropdown mentioned in 1.
  3. Later developers realize articles can contain effectively any data they like whatsoever without any modification to the Model because there's this template_data JSON field that can contain anything. They start ignoring Models entirely; often, new data lives in this one field.
  4. Developers start releasing "news articles" whose fields contain entire JavaScript programs for single-page apps. There are now "dispatch articles" in the db which in terms of number of characters rival novels in length
  5. Because the template filename string can be modified at many points in the Django run loop, it is so modified when users sometimes want entirely different Django Templates. This means that the fact that the previous dropdown selects a Django Template filename as a string becomes more and more irrelevant to Dispatch, to the point I didn't even notice it would do this. It can now longer be assumed that if a certain "Template" is selected in Dispatch, a certain Django Template file is selected. This kills the correspondence between what Dispatch calls a Template and what Django calls a Template
  6. Dispatch Templates therefore now primarily exist to add to an article arbitrarily-structured data with arbitrary contents, including code. When an article is being written that demands some new feature, often devs add a "Template" to Dispatch, which usually, in fact, bears 0 relationship between how Django uses the word "Template".

In absence of an explicit design contract, a Dispatch feature has utterly transformed to the point that certain things now exist on the site that impose requirements on it that would probably have been not implemented as wildly out of scope if there was a design contract, Furthermore, the requirement that gave the feature its name, namely, that when you select a Template in the Dispatch sense, you receive a Template in the Django sense, is now unfulfilled. So it can be said here, a feature developed in such a way it's no longer the same feature

keeganland avatar Jun 24 '21 02:06 keeganland