Separate HTML templates from Go code about ponzu

[crackcomm]

I can't think of any better way to do this than to use pongo2 as template engine. It is highly extensible and probably there is not a thing you can't do with it (eq. see filters).

Project structure in my opinion is partly broken, I feel the cmd/ponzu should not at all be copied to a new project and it could be extensible by using eq. cobra and not using it I found very limiting (eq. command flags). Copying it gives some advantages but those can be easily replicated in a new setting.

I also can't justify the need for not using dependencies but I can understand a need for small codebase, it's helpful to write less code, especially if available is well tested and documented code.

Dependencies in Go are usually vendored using godep, glide or gx. I'm prejudiced for gx but only because of IPFS support and it may seem irrelevant for some.
Vendors along with github.com/ponzu-cms/ponzu in a newly generated project, I feel should be replicated also using any of above.

[nilslice]

@crackcomm - sincerely, thank you for putting such thought into this. I really appreciate your feedback and agree generally on most of what you're saying. I will respond to each point below your points, quoted here:

I can't think of any better way to do this than to use pongo2 as template engine. It is highly extensible and probably there is not a thing you can't do with it (eq. see filters).

This sounds reasonable, especially since there are are a lot of comparisons and checks in my current code. I don't think this will be significantly more efficient, but it will improve readability and make the code easier to extend. My initial attempt to re-write the editor/dom code will likely be using stdlib template/html with just the few template functions I need in the FuncMap. If you would like to contribute a re-write or partial re-write using the pongo2 library, I would happily consider using it in place of mine. However, as I mention later in this comment, I intend to stick with full copy vendoring with no .git in the dependencies.

---

Project structure in my opinion is partly broken, I feel the cmd/ponzu should not at all be copied to a new project and it could be extensible by using eq. cobra and not using it I found very limiting (eq. command flags). Copying it gives some advantages but those can be easily replicated in a new setting.

I thought a lot about whether to copy cmd/ponzu into new projects or not, and ultimately decided that it created the most reliable developer experience when it is fully copied, rather than simply referenced as a package source from the $GOPATH. The main reasons are:

1. Many users will modify the core code to better fit their needs (all of which found in cmd/ponzu's vendor directory) - if it isn't copied, a user would need to manage different versions of the code in multiple directories.
2. Every ponzu project binary is also a CLI. This actually is a nice side-effect, where your shipped binaries can function as a Ponzu CLI on machines that don't have Ponzu installed via go get or otherwise. I have personally found benefits in this during my time working with multiple deployments in different machines.
3. Simplicity & Reliability. I'd like even the most novice gopher to be able to get a project running without any hassle, and when every file and dependency is included, ready to go, the builds are consistent, no additional steps required.

I have not found the need to use any of the CLI packages, but if you could point to a specific feature of one I would be interested to see the benefits. Since it is such a fundamental component to the project, I'd like to keep as much of it as "pure" as possible so that in any event of a dependency being abandoned, Ponzu isn't then responsible to maintain another project.

---

I also can't justify the need for not using dependencies but I can understand a need for small codebase, it's helpful to write less code, especially if available is well tested and documented code.

Fully agree. There are several dependencies in Ponzu now, and I intend to continue to use pre-written, good code whenever possible. However, if the dependency does significantly more than I need, or don't think it provides functionality outside of one component of the project, I prefer to just write the code. In the case of the code discussed in the editor package, I'm a bit torn.

---

Dependencies in Go are usually vendored using godep, glide or gx. I'm prejudiced for gx but only because of IPFS support and it may seem irrelevant for some. Vendors along with github.com/ponzu-cms/ponzu in a newly generated project, I feel should be replicated also using any of above.

These are all good solutions, and each could certainly work for managing dependencies in Ponzu. However, it is a goal of mine to provide an experience to a Ponzu user that is as effortless as possible - and wrangling additional tools to manage dependencies doesn't meet that goal in my experience. Once there is a de facto tool for Go dependency management, we'll use it no doubt. However, the process of $ go get a single package and also getting all of the dependencies is just too simple and too reliable for me to consider something else at the moment. I believe many Ponzu users will be early in their Go careers, and deliberately making it easy to start is crucial to both their success and Ponzu's.

As such, the way I'd like to continue vendoring is by copying the project files directly into the vendor directory, omitting their respective .git directories so no submodules are needed.

[nilslice]

Yes, much of it is total horror and needs to be updated. There are some cases where I like conditionally buffering the html and data. It will be a lot more readable and efficient if it were to be separated into smaller functions and templates though.

[crackcomm]

I can recommend pongo2 as template engine.

[nilslice]

Do you think there is enough complexity in the templates to warrant it? I'd like to use as few dependencies as possible, but if you're willing to help and want to use it, I am all for it.

I currently have all the dependencies copied into cmd/ponzu/vendor without their .git - just to avoid working with submodules.

Project structure like this isn't a strong suit for me, so let me know if you have any suggestions.