<p>Troggle is built on top of the django framework. In 2019 we had let ourselves get rather behind in keeping up to date with the current django version and this held us back from upgrading the operating system - which we needed to do. Troggle uses several community-contributed django plugins and each of these had their own version dependencies. We also got caught up with out of date and deprecated python language features.
<p>A ridiculous amount of work was required to get to a situation where troggle was running on relatively recent and nearly security-in-date versions of python, django, plugins and linux by Summer 2020. We don't want that to happen again.
<li>Django has a mature and reliable release programme: <ahref="https://docs.djangoproject.com/en/dev/releases/">docs.djangoproject.com<wbr>/en/<wbr>dev/<wbr>releases/</a>
<li>Django pre-announces which features will be deprecated: <ahref="https://docs.djangoproject.com/en/dev/internals/deprecation/">docs.djangoproject.com<wbr>/en/<wbr>dev/<wbr>internals/<wbr>deprecation/</a>
<p>We do not just use our own code and django. We also use django plugins (known as "apps") too. These can do such things as image re-sizing, user authentication with captchas, PayPal processing or mailing list integration. Unfortunately django plugins are volunteer efforts and do not have the same defined update management process as django itself, so release schedules are rather random. They cause merry hell when upgrading troggle to use a new version of django.
<p>Every extra plugin increases the "vulnerability surface" of troggle with respect to django upgrade problems so we now only install a new plugin if it is really, really necessary and we have removed as many as we could. For example, when django-staticfiles broke during one upgrade we discovered that we could use troggle.flatfiles as a workaround, so we are not planning on reinstalling staticfiles again.
<p>Well we <ahref="trog2030.html">might not use django indefinitely</a>, but unlike many frameworks the necessary functions are separately replaceable. So this gives us an evolution path. We can incrementally reduce the amount of django we use, replacing it with our own simpler python that does only what we need.
<p>The separate functions within the framework form a "stack". These functions exist in all web application frameworks but in Django they are <ahref="https://docs.djangoproject.com/en/dev/misc/design-philosophies/">loosely coupled</a>.
<li>database: <ahref="https://docs.djangoproject.com/en/dev/topics/db/">mapping</a> to/from python objects and indexing/access routines for all the entries,
<li>request/response (<ahref="https://docs.djangoproject.com/en/dev/ref/request-response/">http GET/POST</a>) including <ahref="https://docs.djangoproject.com/en/dev/topics/auth/default/#auth-web-requests">access control</a> and <ahref="https://www.moesif.com/blog/engineering/middleware/What-Is-HTTP-Middleware/">security middleware</a>,
<li><ahref="https://docs.djangoproject.com/en/dev/topics/http/urls/">URL mapping/dispatch</a> which matches a requested URL with a chunk of python code, and vice versa (declarative and bidrectional),
<li><ahref="https://docs.djangoproject.com/en/dev/topics/templates/">templates</a> which format the results of data queries into HTML pages or JSON data exports
<p>See the <ahref="https://docs.djangoproject.com/en/dev/misc/design-philosophies/">django design philosophy</a>. Note that having a URL dispatcher that supports <ahref="https://docs.djangoproject.com/en/dev/topics/http/urls/#s-reverse-resolution-of-urls">reverse resolution</a> is important: it is a key reason why we need a framework and not just a mess of javascript. We have nearly 100 URL patterns.
