# Integrating sass compilation

K
• 24 May '14

Thoughts on using something like django-compressor or django-pipeline to streamline stylesheet compilation. Not particularly necessary, but would reduce the redundancy of sass and css files at the cost of some dependencies.

django-compressor would also be nice to have for any theme system, as it would tie the sass to the templates. Then both templates and sass could be packaged and distributed independently without much hassle.

nitely
Esteban C Borsani
• 26 May '14

I like the idea, I'll check it out
Have you used it before?

K
• 26 May '14

I've had some great experiences with django-compressor. I've actually already got it mostly working with spirit.
The only drawback I've had is dealing with relative imports. Atm, I'm using an ugly hack to
cd before compiling
which isn't particularly portable. I have some ideas for a rudimentary theme plugin system using this
that I hope to share soon.

K
• 26 May '14

Proof-of-concept theme plugin system is working on my theme branch. With a sample theme here, its nothing but a modified colorscheme. I've only got the category page using the theme currently.

A theme class is just a set of directories and django-compressor options. The class needs to be inserted with entry points. Then it can override any template by dropping it in templates/spirit/theme_name/template_name, static files can be referenced under {{ STATIC_URL }}/spirit/themes/theme_name/static_file.

nitely
Esteban C Borsani
• 1
• 27 May '14

Wow, It looks good.

What I don't like is having to modify the render call on every view...
I was thinking in using a middleware to change the template on the fly... but I'm not sure it's even possible. Reading upon process_template_response makes me think it is.

Overall, it looks like a good start, I'll try it later

K
• 27 May '14

I was wondering about that myself, but wanted a quick demo up first :D I think the middleware approach is much better, but you'll still have to modify every non-generic view to return a TemplateResponse instead of using render.

nitely
Esteban C Borsani
• 1
• 27 May '14

You are right . Also, I'd like Spirit to work without the middleware, so the template path returned by the view should be the same as it is now... am I asking too much?

Another approach would be to monkey patch the render function...

K
• 27 May '14

The only downside I see to middleware is how it might affect integration with existing django projects, possibly swapping templates on a non-Spirit view. Monkey patching the render function... I have no idea what sort of problems that might cause. I like the middleware approach, its fairly cheap and since the signatures for TemplateResponse and render are identical there isn't much work to be done.

I hadn't thought about it, but maybe the theme shouldn't be the user's choice but the site's choice. Let the theme put templates at the same paths to override instead of dynamically choosing a template.

nitely
Esteban C Borsani
• 1
• 27 May '14

The only downside I see to middleware is how it might affect integration with existing django projects, possibly swapping templates on a non-Spirit view.

TemplateResponse has a current_app attribute, so you can check if it's equals to "spirit"

The monkey patching is an awful idea... I was checking something

I hadn't thought about it, but maybe the theme shouldn't be the user's choice but the site's choice. Let the theme put templates at the same paths to override instead of dynamically choosing a template.

That's probably better since Django allows you to override templates at project level.

K
• 28 May '14

@nitely

TemplateResponse has a current_app attribute, so you can check if it's equals to "spirit"

I didn't know about that, problem solved! I really think this is the most flexible way to go, and is still incredibly simple. The middleware is even optional, disable it and you just get the default theme. May I ask why do you want to avoid middleware?

I hadn't thought about it, but maybe the theme shouldn't be the user's choice but the site's choice. Let the theme put templates at the same paths to override instead of dynamically choosing a template.
That's probably better since Django allows you to override templates at project level.

This is really a question of where you want themes applied. Should users be able to individually choose between installed themes, or should a system admin install and enforce only one theme. Most board apps I know of let the user choose, but I've always thought of this as a novelty feature of negligible value.

nitely
Esteban C Borsani
• 1
• 29 May '14

Oh, I don't want to avoid having another middleware, I just don't want Spirit to require it in order to work. Middlewares are kind of magical (not really...) and bugs introduced by them are hard to track down.

This is really a question of where you want themes applied. Should users be able to individually choose between installed themes, or should a system admin install and enforce only one theme. Most board apps I know of let the user choose, but I've always thought of this as a novelty feature of negligible value.

Honestly, I never thought about giving the user the ability to change the theme, that's something old forum systems do and I never really get it... most websites won't allow it. Actually, having to maintain a bunch of themes in your forum can be a pain.

The question is what's the best way to install/change a theme.