I don't know why it's unclear, what I'm proposing, but I'll try a 2nd time:
Something similar to: http://php.net/manual/en/book.dom.php Or, even simpler: - Find Tags, IDs, Classes, etc. in an HTML document. - Something similar to Element.innerHTML to put content into these tags (https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML) - Something similar to Element.setAttribute to change attributes of DOM elements (https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute) - Maybe some validation if the HTML DOM is correct - Possibly some sanitation to check if there are any empty tags or empty tag attributes (i.E. empty content on some meta tag) In short: Load some HTML code, and manipulate the HTML Document Object Model instead of being dependent on placeholders. Yes, a standard library shouldn't do everything. But same goes with templating, so that isn't really an argument against implementing it into the codebase if one of the main foci of Golang is the Web. I wasn't ignoring the Security Model. If someone uses Golang to create a comment section in the web, the same could happen with Templates, if the developer isn't aware of possible security issues. There is no difference if some unchecked user content is injected into <div id="not-so-secure-blogpost>{{blogpost}}</div> or <div id="not-so-secure-blogpost></div>. So I really don't see where "html/template" avoids this issue if some coder doesn't watch out how user content is handled. Escaping the user content (or other security features) can be implemented too, yes - but that should be some other package imho. Kind regards Karv Am Mittwoch, 13. September 2017 21:58:47 UTC+2 schrieb Egon: > > 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.
