Dj-stripe: Overriding template pages

[isaac-jordan]

I'm using dj-stripe in a non-bootstrap project (Materialize to be precise), whats the best way to modify the templates to use Materialize?

What I was planning on doing is to just override all the templates under the djstripe namespace - but is this the proper thing to do? Is there something neater I could do, such as extending them?

[kavdev]

@Sheepzez: we currently only support bootstrap; you're best option at the moment is overriding.

That said, if you have a cool idea on how to support multiple frameworks that's easy to maintain, I'm all for it.

[isaac-jordan]

@kavdev Django crispy-forms supports multiple frameworks by including multiple versions of templates (see https://github.com/django-crispy-forms/django-crispy-forms/tree/dev/crispy_forms/templates), however I don't think much of this idea in terms of the DRY principle. Though it would probably be the easiest to implement.

An idea I had would be to use Django's template language to switch between different frameworks. For example, all the frameworks I know of use a grid system in terms of rows and columns, although different specific CSS classes. We could have a setting that switches the CSS classes between (for example) bootstrap and materialize. Adding a new framework would just involve specifying the corresponding CSS classes.

[kavdev]

I like the latter solution. Have a setting DJSTRIPE_TEMPLATE_FRAMEWORK="bootstrap|materialize|etc." and then adding classes based on that setting is a solid implementation. It does require maintainers to know each framework, but that shouldn't be to difficult.

[lskillen]

@kavdev: Here's a different angle that won't be everyone's cup of tea. We've briefly discussed this before in the context of having an example application, but it might be worth thinking about moving djstripe towards not having any templates/views at all (other than examples). A solid reason for doing so is that as views/templates are very opinionated depending on the context of the application, it is difficult to have a solution that meets everyone's needs (e.g. we use completely custom templates/views). Not having it at all separates you from both having to maintain (or have maintainers) for frameworks that move at different paces, and often have different requirements or ways of doing things (again, opinionated). It would allow you and your contributors to focus solely on the most important part of the application, the core payment handling and object caching. It might even result in "better" code if forced to look at certain bits from the library-only peephole. :-)

@Sheepzez: My apologies for stepping on your issue! Although it'd be good to get the thoughts of above from someone else who might have different "frontend" needs than what is built-in.