expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2024-11-29 21:32:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

Links to other pages doing similar things

Browse Source
This commit is contained in:
Philip Sargent 2022-06-24 23:19:07 +03:00
parent e6ec14fb42
commit c983091fce
2 changed files with 41 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
handbook/computing/todo.html
View File

@ -43,7 +43,13 @@ but now we are just going to use standard HTML5 tags.
Click here if no todo list appears here (because 'frames' have been disabled).</div></a> Click here if no todo list appears here (because 'frames' have been disabled).</div></a>
<hr> <hr>
<h3>Other coding To Do things</h3>
<p>See also these long-running issues which have their own 'to do' implications:
<ol>
<li><a href="/handbook/troggle/trogdesign.html">What Troggle Does Badly - Design Decisions</a>
<li><a href="/handbook/troggle/menudesign.html">New Menu System</a>
<li><a href="/handbook/troggle/trog2030.html">Troggle in 2025-2030</a>
</ol>
<h3>Process Documentation</h3> <h3>Process Documentation</h3>
<details><summary><!--2020-03-26 psargent-->Wallets and new-cave</summary> <details><summary><!--2020-03-26 psargent-->Wallets and new-cave</summary>
<li><!--2020-03-26 psargent-->Explain how to link a new cave into the other caves in <li><!--2020-03-26 psargent-->Explain how to link a new cave into the other caves in

36
handbook/troggle/trog2030.html
View File

@ -68,11 +68,43 @@ all the multi-user non-interference, not Django. So unless we want to roll our o
<div style="color:blue"> <div style="color:blue">
<p>We need to de-cruft troggle *first*: remove 'good ideas' which were never used, trim redundancies and generally reduce it in size significantly. <p>We need to de-cruft troggle *first*: remove 'good ideas' which were never used, trim redundancies and generally reduce it in size significantly.
<p> <p>
We should have a good look at making a list of functions that we will drop and some we replace by parsing cavern output and some we calculate during importing/reading svx files. We should have a good look at making a list of functions that we will drop and some we replace by parsing cavern output and some we calculate
during importing/reading svx files.
<p> <p>
Documentation and a working list of on-going programming projects is the key to keeping troggle in a state where someone can pick it up and do a useful week's work, e.g. extracting the parsed logbooks to use shelve() storage throughout instead of SQL. The next time someone like Radost comes along during the next 5 years we want to be able to use them effectively. Documentation and a working list of on-going programming projects is the key to keeping troggle in a state where someone can pick it up and do a
useful week's work, e.g. extracting the parsed logbooks to use shelve() storage throughout instead of SQL. The next time someone like Radost comes
along during the next 5 years we want to be able to use them effectively.
</div> </div>
<h3>Option Zero.1</h2>
<div style="color:blue">
<p>We should probably review and revise all the over-complex templates, originally written in 2006, which do serious amounts of database querying,
and linked object sub-querying, within the template code. This is a nightmare to maintain and debug, e.g. see
the note at the bottom of <a href="/personexpedition/Wookey/1999">Wookey 1999 trips</a>.
<p>A possible goal would be to create all the data that will be displayed in a page as dictionaries - generated by obviously simple python, with
some Django query optimisations if necessary - which are then handed as 'context' to the Django page template (those files in <var>
troggle/templates/xxx.html</var>), instead of using the Django-specific database object requests within the template sublanguage, e.g.
<code><pre>
{% if persondate.2 %}
&lt;td class="survexblock"&gt;&lt;a href="{% url "svx" persondate.2.survexfile.path %}"&gt;{{persondate.2.name}}&lt;/a&gt;&lt;/td&gt;
{%comment%}
&lt;td class="roles" style="padding-right: 3px; text-align:right"&gt;
{% for survexpersonrole in persondate.2.survexpersonrole_set.all %}
{{survexpersonrole.nrole}}
{% endfor %}
&lt;/td&gt;{%endcomment%}
&lt;td style="text-align:right"&gt;
{{persondate.2.legslength|stringformat:".1f"}} m
&lt;/td&gt;
{% else %}
&lt;td colspan="3"&gt; &lt;/td&gt;
{% endif %}
</pre></code>
</div>
<h3>Things that could be a bit sticky 1 - multi-user safety</h3> <h3>Things that could be a bit sticky 1 - multi-user safety</h3>
<p>Multi-user synchronous use could be a bit tricky without a solid multi-user database sitting behind the python code. So removing all the SQL database use may not be what we want to do after all. <p>Multi-user synchronous use could be a bit tricky without a solid multi-user database sitting behind the python code. So removing all the SQL database use may not be what we want to do after all.
<p>Under all conceivable circumstances we would continue to use WGSI or <p>Under all conceivable circumstances we would continue to use WGSI or