Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Template library #117

Open
bouncepaw opened this issue Nov 5, 2021 · 1 comment · May be fixed by #236
Open

Template library #117

bouncepaw opened this issue Nov 5, 2021 · 1 comment · May be fixed by #236

Comments

@bouncepaw
Copy link
Owner

We use the quicktemplate library for almost all of HTML templating tasks in the project.

Contra:

  • Yet another dependency (all dependencies fail and are not to be trusted)
  • Yet another non-standard thing
  • We have twice as many files (.qtpl and .qtpl.go)
  • People are irritated for some reason?

Pro:

  • The core idea of the library (templates are normal Go functions) makes sense
  • The syntax of the templating language is very expressive
  • The library is quite fast, they say

I do not think changing quicktemplate to any other non-stdlib templating solution is a good idea. But what about stdlib's html/template?

=> https://godocs.io/html/template

Contra:

  • The API is ridiculous. You have to parse each template (and that may fail) and then you have to ‘execute’ it (and that may fail too). Simply unbearable
  • If we use html/template, it will be easier to implement template configuration, which is undesirable

Pro:

  • It is in stdlib
  • If we store the templates as separate .html files, every text editor will have a proper syntax highlighting. Compare with .qtpl which requires additional configuration everywhere

So, what is better? Cross your sword!

@bouncepaw
Copy link
Owner Author

After like six experiments, I'm starting to like this approach:

  • stdlib templates
  • l10n are done using {{block}} in place in English
  • they are then redefined for Russian for Russian versions of templates

Take a look at how categories views are done.

This approach also covers #138.

@bouncepaw bouncepaw linked a pull request Jun 11, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant