Re: mustache documentation and recommedations

"[email protected]" <[email protected]> writes:

      Notice how this template definition requires knowledge of
      the CFE bundle names "g" and "dls_cs_ssh".

      Now, suppose we refactor the CFE code and rename
      "dls_cs_ssh" to something else. And suppose, as is quite
      probable, we overlook (or similarly forget) this
      corresponding change in a different file. Then this template
      will start failing, as it introduces unexpected errors onto
      the client machines. The refactoring process is fragile.

      Now in theory we can address this by using "template" data.
      This would allow the "vars" items to be simplified to:

      ------------------------------------------------------------
      {{#primary_network_ip}} ListenAddress {{.}}
      {{/vprimary_network_ip}}

      {{#denied_users}} DenyUsers {{.}} {{/denied_users}}
      ------------------------------------------------------------

      because the calling bundle can handle the data much more
      cleanly and consistently and, where appropriate, use CFE's
      "$(this.bundle)".



      (We have done such refactoring in other places and it has
      been very successful.)

Yeah, I agree that using explicit `template_data' is better in the long
run than leveraging `datastate()' which is convenient and rich with
data.

It allows for easier delegation People unfamiliar with CFEngine could be
responsible for managing the template and (depending on how it's
arranged) the data. Policy can be re-factored, variable and bundle names
could change without affecting how the template renders.

It also makes for shorter strings, arguably making reading things later
a bit easier.

However, using explicit `template_data' means that you have to prepare
more. If you want to use dynamic values you will need to do some work to
pull those into your explicit data. If you want to delegate
responsibility for some static data to someone else you will need to
maintain an API that merges their static data in with the dynamic data
from policy. And, if you want to use classes for conditional blocks, you
have to get the classes into that data-structure which is not as easy as
it could be (IMHO at least).

This question has come up on the mailing list before, see this post
[here] that shows an example pulling the currently defined classes from
`datastate()' in to a data structure which can be used to provide
`template_data'. I find it quite fugly and limited, but it has worked
for me in the past.

I filed at least one ticket related to this (there are very plausibly
more): <https://tracker.mender.io/browse/CFE-2908>


[here]
<https://groups.google.com/g/help-cfengine/c/VktwAdsQ3zc/m/FplxWLezAwAJ>

-- 
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/878rhymli4.fsf%40northern.tech.



--
Nick Anderson | Doer of Things | (+1) 785-550-1767 | https://northern.tech

-- 
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/878rhymli4.fsf%40northern.tech.