@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 "<!--
summaryData -->", "[summary.Data]", "(\summaryData/)" or anything else with
the needed input. One could also see the whole "<div
class="summaraData"></div>" 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 <div> 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 <div
class="summaryData">[...]</div> it can be reused as the designer sees fit.
Let's, for example, assume 2 cases.
Case 1: Main file has '[...]<main></main>[...]', 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 '[...]<main><div class="summaryData"></div><div
class="anotherDiv"></div></main>', 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.
