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