Is your feature request related to a problem? Please describe.
Since Bootstrap v5.0 is stable, it would be nice if apps spawned by EspressoDB could use this version instead of v4.x.
This applies to new as well as existing apps.
The main problem (besides html adjustments) is that it is unfortunately not as easy as just switching the base template (and settings) in the spawned project as also, for example, the admin views run {% load bootstrap4 %}.
Describe the solution you'd like
I can see two scenarios (or some middle ground) being applicable here; which both require an adjustment on the EspressoDB side.
Make changes entirely verbose: copy all the files which are likely to introduce third party api changing behavior in the long run into the spawend EspressoDB project. I.e., have a sub directory templates/espressodb/ in which you can find the base, index and other templates. This makes it easier for users to change the projects to their needs.
Behind the scenes: Write new custom API templatetags inside EspressoDB which are used in EspressoDBs internal tempaltes (base, admin, ...). These templatetags could either wrap, for example, the bootstrap templatetags or be entirely customized. The user could choose which template is used by using custom settings like ESPRESSODB_BOOTSTRAP_VERSION = 4 (and some validation). This way, we can ensure that the API never breaks and users do not have to adjust (or at least adjust less) when dependencies change. This case is a bit tricky as it requires to install different packages. One could do a pip install espressodb to default to v5 and pip install espressodb[bootstrap4] to v4.
I am not entirely sure if this generally also means that we have to provide bootstrap-4 and bootstrap-5 html templates or if there is some middle ground which both versions render properly (i.e., jumbotrons are gone and ml was changed to me, ...)
I could also see a mixture of two things happening. I.e., expose the to base templates to spawned apps and have small rendering expressions like forms on admin pages use custom templatetags. In any case, both scenarios can be implemented in a backwards compatible way but require a migration guide (docs) for users to upgrade existing projects.
I generally believe that we should at least copy the base template to new projects, in any case, as I frequently have to look up this template to identify the names of blocks.
Is your feature request related to a problem? Please describe.
Since Bootstrap v5.0 is stable, it would be nice if apps spawned by EspressoDB could use this version instead of v4.x.
This applies to new as well as existing apps.
The main problem (besides html adjustments) is that it is unfortunately not as easy as just switching the base template (and settings) in the spawned project as also, for example, the admin views run
{% load bootstrap4 %}.Describe the solution you'd like
I can see two scenarios (or some middle ground) being applicable here; which both require an adjustment on the EspressoDB side.
templates/espressodb/in which you can find the base, index and other templates. This makes it easier for users to change the projects to their needs.ESPRESSODB_BOOTSTRAP_VERSION = 4(and some validation). This way, we can ensure that the API never breaks and users do not have to adjust (or at least adjust less) when dependencies change. This case is a bit tricky as it requires to install different packages. One could do apip install espressodbto default tov5andpip install espressodb[bootstrap4]tov4.I am not entirely sure if this generally also means that we have to provide bootstrap-4 and bootstrap-5 html templates or if there is some middle ground which both versions render properly (i.e.,
jumbotrons are gone andmlwas changed tome, ...)I could also see a mixture of two things happening. I.e., expose the to base templates to spawned apps and have small rendering expressions like forms on admin pages use custom templatetags. In any case, both scenarios can be implemented in a backwards compatible way but require a migration guide (docs) for users to upgrade existing projects.
I generally believe that we should at least copy the base template to new projects, in any case, as I frequently have to look up this template to identify the names of blocks.