From c983091fce87416db6e8acdadf425d6a4810be7b Mon Sep 17 00:00:00 2001 From: Philip Sargent Date: Fri, 24 Jun 2022 23:19:07 +0300 Subject: [PATCH] Links to other pages doing similar things --- handbook/computing/todo.html | 8 +++++++- handbook/troggle/trog2030.html | 36 ++++++++++++++++++++++++++++++++-- 2 files changed, 41 insertions(+), 3 deletions(-) diff --git a/handbook/computing/todo.html b/handbook/computing/todo.html index b05c658ee..b0b115795 100644 --- a/handbook/computing/todo.html +++ b/handbook/computing/todo.html @@ -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).
- +

Other coding To Do things

+

See also these long-running issues which have their own 'to do' implications: +

    +
  1. What Troggle Does Badly - Design Decisions +
  2. New Menu System +
  3. Troggle in 2025-2030 +

Process Documentation

Wallets and new-cave
  • Explain how to link a new cave into the other caves in diff --git a/handbook/troggle/trog2030.html b/handbook/troggle/trog2030.html index 424895f6b..2495a306c 100644 --- a/handbook/troggle/trog2030.html +++ b/handbook/troggle/trog2030.html @@ -68,11 +68,43 @@ all the multi-user non-interference, not Django. So unless we want to roll our o

    We need to de-cruft troggle *first*: remove 'good ideas' which were never used, trim redundancies and generally reduce it in size significantly.

    -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.

    -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.

    + +

    Option Zero.1

    +
    +

    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 Wookey 1999 trips. + +

    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 +troggle/templates/xxx.html), instead of using the Django-specific database object requests within the template sublanguage, e.g. +

    +  {% if persondate.2 %}
    +    <td class="survexblock"><a href="{% url "svx" persondate.2.survexfile.path %}">{{persondate.2.name}}</a></td>
    +        {%comment%}
    +        <td class="roles" style="padding-right: 3px; text-align:right">
    +        {% for survexpersonrole in persondate.2.survexpersonrole_set.all %}
    +          {{survexpersonrole.nrole}}
    +        {% endfor %}
    +        </td>{%endcomment%}
    +<td style="text-align:right">
    +    {{persondate.2.legslength|stringformat:".1f"}} m
    +    </td>
    +  {% else %}
    +    <td colspan="3"> </td>
    +  {% endif %}
    +  
    + +
    +

    Things that could be a bit sticky 1 - multi-user safety

    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.

    Under all conceivable circumstances we would continue to use WGSI or