Changes between Initial Version and Version 1 of Ticket #27359, comment 8


Ignore:
Timestamp:
Jan 26, 2017, 7:55:04 PM (8 years ago)
Author:
Carl Meyer

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #27359, comment 8

    initial v1  
    1 Given the current API, we are effectively asking projects like django-cms or crispy-forms (any third-party project that wants to load and render a Django template using the project's settings) to require their users to specify some setting (like `DJANGO_CMS_TEMPLATE_ENGINE`) if the project has more than one DjangoTemplate engine configured. This may be OK: it's explicit and gives the project fine-grained control per third-party project. On the downside, it's unlikely to be the obvious first-choice for the author of a third-party project; the obvious first choice is to just try instantiating `Template` directly, and even worse, this will probably appear to work fine until they think to test (or more likely, one of their users reports a bug) with multiple configured DTL engines.
     1Given the current API, we are effectively asking apps like django-cms or crispy-forms (any third-party app that wants to load and render a Django template using the project's settings) to require their users to specify some setting (like `DJANGO_CMS_TEMPLATE_ENGINE`) if the project has more than one DjangoTemplate engine configured. This may be OK: it's explicit and gives the project fine-grained control per third-party app. On the downside, it's unlikely to be the obvious first-choice for the author of a third-party app; the obvious first choice is to just try instantiating `Template` directly, and even worse, this will probably appear to work fine until they think to test (or more likely, one of their users reports a bug) with multiple configured DTL engines.
    22
    3 IMO currently direct instantiation of `Template` is an attractive nuisance that appears easy and obvious and only breaks in edge cases, at which point the person who hits the problem (the project owner) has no reasonable way to fix it (without forking the third-party project).
     3IMO currently engine-less instantiation of `Template` is an attractive nuisance that appears easy and obvious and only breaks in edge cases, at which point the person who hits the problem (the project owner) has no reasonable way to fix it (without forking the third-party app).
    44
    5 I think we must do one of two things. We could a) deprecate and eventually remove direct instantiation of `Template` altogether, removing the attractive nuisance and requiring everyone to always be explicit from the start. Or we could b) add a "default DTL engine" marker, as suggested in this ticket, so that when a third-party project does the easy and naive thing (directly instantiate `Template`), a project owner with multiple DTL engines configured has some recourse to fix it without forking.
     5I think we must do one of two things. We could a) deprecate and eventually remove engine-less instantiation of `Template` altogether, removing the attractive nuisance and requiring everyone to always be explicit from the start. Or we could b) add a "default DTL engine" marker, as suggested in this ticket, so that when a third-party app does the easy and naive thing (directly instantiate `Template`), a project owner with multiple DTL engines configured has some recourse to fix it without forking.
    66
    77I think (b) may be the more practical solution, and kinder to our user base.
Back to Top