Re: [go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?
@Karv Prime I was looking for a library for this but i have not been able to find any yet. Did you have any luck? I have worked with http://www.thymeleaf.org/ for Java extensively and I really enjoyed it. Its a lot easier to work with the front-end people with legal html. Dom manipulation gives a lot more separation than is possible with simple template/injection in my opinion. Maybe we should start on making a golang lib for this... :-) @Marvin Renich Not to start a war on which approach is better but when using the dom manipulation. Hello, {{.Name}}, you last logged in on {{.PrevLogin}}. would be: All this text will be replaced by the hello var. This way the front end developer can test with long/short texts (user names) and see how they look Also if doing localization you would not have static text like that in your html template. Also: - is much better IMO. The front-end guy can put in whatever html he needs to test the div content and it will all get replaced when the dom is parsed. -- 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.
Re: [go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?
* Karv Prime[170914 13:16]: > I wouldn't agree on "there is not even a need for the wrapper" part. > If the HTML tags are produced entirely by code, it comes with its own > issues - suddenly there is a thing that wasn't in the markup - it would > probably reduce maintainability. If there's already a file with class="summaryData">[...] it can be reused as the designer sees fit. > Let's, for example, assume 2 cases. As I said in my previous post, if the element is useful for the designers, e.g. to position or align the whole replacement summaryData (which I am assuming is significantly more complicated than some unformatted text), then by all means put it in. The point about not needing the tags was really more directed at use cases where you are inserting some simple replacement in the middle of the content of a larger element, e.g. Hello, {{.Name}}, you last logged in on {{.PrevLogin}}. Doing this with DOM manipulation requires extra elements around the items to be replaced. The snippet above is much easier to read and maintain than the corresponding HTML with elements, and produces smaller, more readable HTML to send over the wire. The tag also _may_ not be needed in cases where the replacement content is significantly larger, contains multiple elements, and a container is not needed to separate the replacement from elements before and after it. > Case 1: Main file has '[...][...]', the module is the > aforementioned div with summary data. The coder has to know where to put > it. Does it belong directly in main? Is it inside another element? The > backend dev doesn't know without input from the frontend devs - so backend > devs are involved deeper into the frontend design as they should be. No, the main file has {{.summaryData}} The program is told where to put it by the designer. My point was that the designer must use something to identify the location for the replacement, and there is little difference to the designer whether the file has or {{.summaryData}} I posit that the second is much easier to recognize as a placeholder for data that will be supplied later; easier for the designers, easier for the programmers, easier for outside consultants unfamiliar with the project, easier for new hires, and easier for management. ...Marvin -- 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.
Re: [go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?
@Andy Balholm: Perfect. I've seen some other template engines where that didn't happen at all and the artifacts stayed. @Marvin Renich: Yet tags, classes and ids are HTML standard syntax and used for styling and scripting purposes. {{[...]}} is only a placeholder. It makes no difference per se, that's true. One can also replace "", "[summary.Data]", "(\summaryData/)" or anything else with the needed input. One could also see the whole "" as a placeholder and replace it accordingly (problematic as soon as spaces and newlines are involved ^^). I wouldn't agree on "there is not even a need for the wrapper" part. If the HTML tags are produced entirely by code, it comes with its own issues - suddenly there is a thing that wasn't in the markup - it would probably reduce maintainability. If there's already a file with [...] it can be reused as the designer sees fit. Let's, for example, assume 2 cases. Case 1: Main file has '[...][...]', the module is the aforementioned div with summary data. The coder has to know where to put it. Does it belong directly in main? Is it inside another element? The backend dev doesn't know without input from the frontend devs - so backend devs are involved deeper into the frontend design as they should be. Case 2: Main file has '[...]', the module only has the '[...]' content of the div. The coder doesn't need to know where to put it. Push it around in the frontend, no one has to care about it. One could also put the information which file belongs to the class/id/tag into a database, so the frontend devs can do that all by themselves and no coder is needed. ID: 1, Path: 'modules', File: 'summarydata.html', type: 'class', name: 'summaryData'. Finished. If the wrapper element is necessary or not... usually it should be in most of these cases as newer data can be loaded via script or at least the element is styled/positioned in a certain way. That approach should be done with standalone-modules only. If there's a page with i.E. contact information, one shouldn't put everything inside a certain div and create a div-soup - I would even say that this is most certainly static data as companies don't move around that often (yet for a CMS it should be in the database, sure) - it really depends on the case, but I wouldn't overdo it for the main parts of the page. User provided content is a different story though. But, as you've said, no difference if it's a class/id/tag or a template placeholder. -- 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.
Re: [go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?
@Andy Balholm: Perfect. I've seen some other template engines where that didn't happen at all and the artifacts stayed. @Marvin Renich: Yet tags, classes and ids are HTML standard syntax and used for styling and scripting purposes. {{[...]}} is only a placeholder. It makes no difference per se, that's true. One can also replace "", "[summary.Data]", "(\summaryData/)" or anything else with the needed input. One could also see the whole "" as a placeholder and replace it accordingly (problematic as soon as spaces and newlines are involved ^^). I wouldn't agree on "there is not even a need for the wrapper" part. If the HTML tags are produced entirely by code, it comes with its own issues - suddenly there is a thing that wasn't in the markup - it would probably reduce maintainability. If there's already a file with [...] it can be reused as the designer sees fit. Let's, for example, assume 2 cases. Case 1: Main file has '[...][...]', the module is the aforementioned div with summary data. The coder has to know where to put it. Does it belong directly in main? Is it inside another element? The backend dev doesn't know without input from the frontend devs - so backend devs are involved deeper into the frontend design as they should be. Case 2: Main file has '[...]', the module only has the '[...]' content of the div. The coder doesn't need to know where to put it. Push it around in the frontend, no one has to care about it. One could also put the information which file belongs to the class/id/tag into a database, so the frontend devs can do that all by themselves and no coder is needed. ID: 1, Path: 'modules', File: 'summarydata.html', type: 'class', name: 'summaryData'. Finished. If the wrapper element is necessary or not... usually it should be in most of these cases as newer data can be loaded via script or at least the element is styled/positioned in a certain way. That approach should be done with standalone-modules only. If there's a page with i.E. contact information, one shouldn't put everything inside a certain div and create a div-soup - I would even say that this is most certainly static data as companies don't move around that often (yet for a CMS it should be in the database, sure) - it really depends on the case, but I wouldn't overdo it for the main parts of the page. User provided content is a different story though. But, as you've said, no difference if it's a class/id/tag or a template placeholder. -- 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.
Re: [go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?
* Karv Prime[170914 11:14]: > ... - yet > there's the disadvantage of the need to put artifacts into the markup which > then get replaced by the wanted content You have to do that anyway, you just use different artifacts. Each location where a substitution will occur must be uniquely identified, whether it is or {{.summaryData}}. If summaryData has any HTML at all, then the programmer and the designer must coordinate on styles (at least style names) anyway (the Template Animation post glosses over this point), so there is not even a need for the wrapper; just put {{.summaryData}} and let the program supply any necessary style or class attributes. The resulting HTML will have one less unnecessary wrapper element. I'm not saying the wrapper can't be in the template if it is useful for other purposes, but that it is not needed for the template substitution, whereas it is needed as a placeholder when doing DOM manipulation. ...Marvin -- 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.
[go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?
As it would get a little bit confusing if I'd reply to everyone with a single post, I'll answer in a single post. I hope you don't mind. At least now it's past 16:00 and not past 04:00 and I have a clearer mind. ^^ @Egon: I've read the whole article - yes, many coders sadly do forget about proper sanitization of user-input. As I'm pretty focused on security, I know about the implications of many design-approaches. Easy-to-use approaches are neat and in that certain case super useful - but sadly not for my use-case. ^^ @Andy Balholm: No, the "blog posts" are not HTML. Again: There is a reusable HTML snippet. That snippet can be filled with user content - which truly needs to be sanitized due to security concerns. If the snippet gets sent to the user via asynchronous request there's nothing more to do as JS takes the part with putting it into its place. But if the whole page has to be rendered, that snippet needs to be put into the page, before the whole page gets sent to the user. The other way would be to leave the complete rendering to the user browser which comes with its very own disadvantages (i.E. no scripting available, etc.). I thought that the whole package auto-sanitizes the content as you've stated before. Now, okay, it's usable for that use case. It's not perfect with all the artifacts one needs to put into the HTML code, but if necessary I can work with that. ^^ @Marvin Renich: Thank you for this information. I'm new to Golang and I probably misunderstood one comment here for "the (whole) template package does automatic escaping), so I didn't look further - my mistake. So it would be possible to implement everything via the template package - yet there's the disadvantage of the need to put artifacts into the markup which then get replaced by the wanted content (I have to look into it further - if there's an error if there is no data for some template code it's perfectly fine... otherwise it will look like some websites where the artifacts are visible to the user if they didn't get replaced). -- 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.
[go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?
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 id="not-so-secure-blogpost>{{blogpost}} or id="not-so-secure-blogpost>. 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. >>> -> '' instead of '{{.content}}' >>> -> '' instead of '>> 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
[go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?
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 . 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. >> -> '' instead of '{{.content}}' >> -> '' instead of '> 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
[go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?
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. > -> '' instead of '{{.content}}' > -> '' instead of ' 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.