4 ms·

Its probably because I needed a page to act differently if it was embedded or not, desktop or phone, and if the user was logged in or not. So in essence 2x2x2=8

Its probably because I needed a page to act differently if it was embedded or not, desktop or phone, and if the user was logged in or not. So in essence 2x2x2=8 different behaviours. Even things like links would need to change inside the page. Easier, and shorter to write a function that changes the output. Then to battle the templating language, or write and support 8 different views.

viraptor 6y ago
I don't get it... templates sound like what you want here. You want links to change based on some conditions? Why not use {{ generate_link|safe }} on one generic template?
- dukeofdoom 6y ago
  Thats what I ended up doing most of the time. Still ended up with a lot of if then code in the html template. Making it more verbose than it would have been, had I just generated the html page inside a function.
  - DangitBobby 6y ago
    You can often generate a structure such as nested dicts and lists of dicts to pass via the template context to achieve your desired layout. This lets you avoid complex logic via template tags but still have the benefits of the templating system.
  - viraptor 6y ago
    > I just generated the html page inside a function. But that's also a template - just your own kind rather than framework's. I guess it's hard to really understand the tradeoffs here without concrete examples... which is not great for HN either.
salmo 6y ago
Some of that logic (logged in, or exposing stuff based on RBAC) are usually pretty easy in templates of any flavor. And that's usually where I have to revisit for changes, so maintenance shouldn't be bad. Sometimes I do common things like stored markdown->html by injecting filters into the template context. So {{ comment | markdown }}. For completely different presentations, you can have separate templates returned by the same endpoint. But it sounds like that actually should just be a separate endpoint altogether. You could use template inheritance for code reuse, but you can also walk into over complicating that if those start diverging over time. Handling screen variety is best done with CSS (and JS when you have to do something hacky). The HTML shouldn't need to change for that. Even back to JSPs or early PHP, I learned the hard way to avoid sticking business logic in my "templates" or sticking HTML in my code. Either will work, but maintaining it sucks. And if it is a successful project and you need to change the design in year 3, it'll easily result in a nearly complete rewrite. I know the cool thing to do now is even just expose the data via REST or GraphQL and do a SPA, but I don't do frontend work enough to get over that learning curve.

viraptor 6y ago

I don't get it... templates sound like what you want here. You want links to change based on some conditions? Why not use {{ generate_link|safe }} on one generic template?

dukeofdoom 6y ago
Thats what I ended up doing most of the time. Still ended up with a lot of if then code in the html template. Making it more verbose than it would have been, had I just generated the html page inside a function.
- DangitBobby 6y ago
  You can often generate a structure such as nested dicts and lists of dicts to pass via the template context to achieve your desired layout. This lets you avoid complex logic via template tags but still have the benefits of the templating system.
- viraptor 6y ago
  > I just generated the html page inside a function. But that's also a template - just your own kind rather than framework's. I guess it's hard to really understand the tradeoffs here without concrete examples... which is not great for HN either.

salmo 6y ago

Some of that logic (logged in, or exposing stuff based on RBAC) are usually pretty easy in templates of any flavor. And that's usually where I have to revisit for changes, so maintenance shouldn't be bad. Sometimes I do common things like stored markdown->html by injecting filters into the template context. So {{ comment | markdown }}. For completely different presentations, you can have separate templates returned by the same endpoint. But it sounds like that actually should just be a separate endpoint altogether. You could use template inheritance for code reuse, but you can also walk into over complicating that if those start diverging over time. Handling screen variety is best done with CSS (and JS when you have to do something hacky). The HTML shouldn't need to change for that. Even back to JSPs or early PHP, I learned the hard way to avoid sticking business logic in my "templates" or sticking HTML in my code. Either will work, but maintaining it sucks. And if it is a successful project and you need to change the design in year 3, it'll easily result in a nearly complete rewrite. I know the cool thing to do now is even just expose the data via REST or GraphQL and do a SPA, but I don't do frontend work enough to get over that learning curve.