On Thursday, 14 September 2017 00:11:11 UTC+3, Karv Prime wrote: > > I don't know why it's unclear, what I'm proposing, but I'll try a 2nd time: >
The devil is in the details :), but this makes it clearer. I just had few different ideas floating around in my head that could fit the first description. (e.g. is it similar to shadow-dom, direct dom manipulation, dom manipulation through some abstraction, separate layers etc.) > > 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.
