Re: [go-nuts] Re: "html/dom" alternative to html/template for true separation of concerns?

[jens . schoedt]

@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?

[Marvin Renich]

* 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?

[Karv Prime]

@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]

@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?

[Marvin Renich]

* 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?

[Karv Prime]

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?

[Egon]

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?

[karv . prime]

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?

[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 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.