search

oscarmlage / django-cruds-adminlte

django-cruds is simple drop-in django app that creates CRUD for faster prototyping
BSD 3-Clause "New" or "Revised" License
424 stars 82 forks source link

Improve template structure #127

Open telenieko opened 5 years ago

telenieko commented 5 years ago

Currently, there is a base.html which defines about 20 blocks with at least 4 includes which in turn define some other blocks. Also, some of the includes start with "_" which would imply "This is library private, do not override or bad things will happen to you".

But, by default, if you want to customize the sidebar (which you must, there's no point to it otherwise!) you have to either:

This is just an example. Template customization could be better.

I have two proposals, and asking for opinions:

"_"preffixed templates

Make all templates _private and provide, from the library, a set of non-privately named templates that ONLY extends the private one. So the library user might override those templates and only override the blocks.

So, for the sidebard example: The library would provide "_main_sidebar.html" and "main_sidebar.html" which would only be an extends of the former and nothing else. Now, base.html would include "main_sidebar.html" instead of "_main_sidebar.html" so the library user can easily override main_sidebar.html and redefine de blocks.

Full base.html

The first proposal has a drawback: what if I want different sidebars for different stuff? Maybe on create views I want red headers, and jumping kittens on delete views ... By design, you cannot override a block from main_sidebar.html from you template (that extends from base). Because the way {% include %} works.

BUT, what if cruds_adminlte would "compile" the base.html into a global template where "include" is pre-processed so that when you do {% extends "superbase" %} you can then redefine all the blocks you want.

My 0.02

The first approach is clean and simple, but feels kind of limiting for the purpose of the library (that is, certain customizations by library users need too much work or overengineering).

The second approach is harder to implement, but from the library user point of view it is incredibly nice: If I am in a "list.html" template and I want to ovveride the copyright notice on the footer I can do it from there.

What do you thing?

oscarmlage commented 5 years ago

IMHO second approach is definitely better for the end user and, as you said before, the main goal of this library is to make things happen in an easy way for the developer using it.

So, my +1 is for the pre-processed option.

telenieko commented 5 years ago

An initial implementation is available in #132 for testing.