If you want to manipulate HTML files then there is https://godoc.org/golang.org/x/net/html, but it comes with all the dangers of potential injection attacks and so on... which "html/template" avoids. Writing something that injects into the specific nodes and afterwards encodes shouldn't be a big problem.
If you want to write HTML directly from code then writing a simple html encoder with the necessary models isn't too complicated (https://github.com/egonelbre/exp/blob/master/htmlrender/main.go) But the huge con you are ignoring is the Security Model. (https://rawgit.com/mikesamuel/sanitized-jquery-templates/trunk/safetemplate.html#problem_definition) Anyways it's unclear what you are proposing or needing: in general standard libraries shouldn't do everything and probably this, whatever it is, should belong to a 3-rd party package. + Egon On Wednesday, 13 September 2017 22:02:02 UTC+3, Karv Prime wrote: > > Hello, > > I only recently found my way to go. I'm a (former?) fullstack web-dev and > as I ran into a PHP related problem (DOMDocument not working with HTML5 > tags, I'd choose another solution stack if the language wouldn't be a fixed > point in history) I was looking if Go already has a good way to manipulate > HTML files. The templating is fine, but in my humble opinion there's a > problem... > > Problem: IMHO templating in the current form is flawed. To insert > placeholders (i.E. "{{.nav}}") probably isn't an optimal solution as it > just tells the code "hey, act upon me". It seems to be a shallow solution > to prevent code-mixins, but fails to really separate the concerns. > > Solution: If there would be a Go package to directly manipulate the DOM it > would be very helpful to separate Markup and Code. The code would act onto > the markup file (*.html) to create the page/site/module/... (whatever is > needed). > > Pros: > - Frontend devs could create their own pages, modules, etc. without > thinking about any special tags they'd need. > -> '<main></main>' instead of '<main>{{.content}}</main>' > -> '<meta name="description" content="">' instead of '<meta > name="description" content="{{.description}}">' > - Error/Exception if some tag/id/class/... has not been found instead of > admins possibly not knowing about it. > -> You can act upon it and tell the users "Oops, something went wrong, > we're looking into it." so they know that the current state of the site > isn't what they should see. > -> Better an empty element (and the admin knows about it) instead of users > seeing placeholders. > - It's easier to avoid any problems with funny users trying to trick the > system. > - In theory faster than templating solutions (untested claim, so there's a > big questionmark)? > - It prefers modular frontends (main site, nav, main content, reusable > modules (i.E. for items on a sales platform)) instead of a single file with > placeholders > - It prefers cleaner code and true SoC instead of the ofttimes preferred > workflow "just a little HTML in the code to create each item faster" or > vice versa. > - ... > > Cons: > - If there are elements unknown to the backend-devs, they will probably > stay empty > -> Possible solution could be some kind of taint-checking for empty > elements after page creation > - "Duplicate" code if there's frontend-scripting that is changing > parameters accordingly to AJAX results, but that's almost unavoidable. > - Probably more communication needed between backend- and frontend-devs > -> Possible solution, the aforementioned taint-checking, to see these > problems in testing, if they should arise > - ... > > Feel free to contribute your thoughts, other pros/cons, etc. :) > > Kind regards > Karv > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
