expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-12-09 07:14:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

django documentaiton updates

Browse Source
This commit is contained in:
Philip Sargent
2021-03-30 01:42:41 +01:00
parent fa81616797
commit ecaaec7927
7 changed files with 41 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
handbook/troggle/trogdjango.html
View File

@@ -8,10 +8,24 @@
<body><style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
<h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>Django and Troggle</h1>
<h3>Django Versions and troggle</h3>
<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.
<h3>Three sentence intro to Django for python programmers</h3>
<ul>
<li>There are many 'magic' function calls autogenerated. So when we create a <var>'Cave'</var> class (subclass of Django <var>Model</var>), with an instance <var>'caveenetrance'</var> we automagically define functions such as:
<ul>
<li><var>Cave.objects.filter()</var>
<li><var>Cave.objects.all()</var>
<li><var>Cave.caveandentrance_set.all</var>
</ul>
note that the suffix on a name '<var>'_set</var> actually denotes a function call to the database. Don't let this upset you.
<li>You will get very familiar with the <a href="https://docs.djangoproject.com/en/2.2/">online documentation</a>. be sure to be looking that the flavour for the right release of Django (indicated on the bottom-right of the screen: the link here goes to v2.2). You can read it in Polish, Indonesian, Brazilian-Portuguese or whatever if you prefer.
<li>Django has a good process for migrating both the python code and the SQL database to later versions of Django via <a href="https://docs.djangoproject.com/en/2.2/topics/migrations/">'migrations'</a>. Note that even though Expo imports all the data from files and its database is ephemeral (but it is intensely used for cross-referencing), the database schema still needs to be migrated.
</ul>
<h4>Django versions and deprecation</h4>
<a href="https://www.djangoproject.com/download#supported-versions">
<img border="1" class="onright" width="250px" src='release-roadmap.3c7ece4f31b3.png'/></a></a>
@@ -19,6 +33,7 @@
<li>Django has a mature and reliable release programme: <a href="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: <a href="https://docs.djangoproject.com/en/dev/internals/deprecation/">docs.djangoproject.com<wbr>/en/<wbr>dev/<wbr>internals/<wbr>deprecation/</a>
<li>Django release schedule: <a href="https://www.djangoproject.com/download/">supported versions timetable</a>
<li>Significant new Django versions are released every 8 months. Deprecated features after removed after the two subsequent versions.
</ul>
<h4>Django plugins</h4>
@@ -30,12 +45,12 @@
<p>Well we <a href="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 <a href="https://docs.djangoproject.com/en/dev/misc/design-philosophies/">loosely coupled</a>.
<p>The stack is:
<ul>
<li>database: <a href="https://docs.djangoproject.com/en/dev/topics/db/">mapping</a> to/from python objects and indexing/access routines for all the entries,
<ol>
<li>SQL database: <a href="https://docs.djangoproject.com/en/dev/topics/db/">mapping</a> to/from python objects and indexing/access routines for all the entries (sqlite, MySQL, MariaDB, postgres all work)
<li>request/response (<a href="https://docs.djangoproject.com/en/dev/ref/request-response/">http GET/POST</a>) including <a href="https://docs.djangoproject.com/en/dev/topics/auth/default/#auth-web-requests">access control</a> and <a href="https://www.moesif.com/blog/engineering/middleware/What-Is-HTTP-Middleware/">security middleware</a>,
<li><a href="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><a href="https://docs.djangoproject.com/en/dev/topics/templates/">templates</a> which format the results of data queries into HTML pages or JSON data exports
</ul>
</ol>
<p>See the <a href="https://docs.djangoproject.com/en/dev/misc/design-philosophies/">django design philosophy</a>. Note that having a URL dispatcher that supports <a href="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.