Improve template structure

[telenieko]

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:

• Extend base.html and override the block that includes the sidebar so you can include you own sidebar that extends from the library provided one
• Override the library provided sidebar (which you can't extend from as you should not extend the template you are overriding!)

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]

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]

An initial implementation is available in #132 for testing.