Use a config file to specify custom templates

[xcoulon]

The CLI should have an extra flag to specify the path to a YAML config file (with sensible default, eg .config.yaml) which would allow users to specify their own custom templates, both for inline and block macros.

Something like:

macros:
  - hello:
    - inline: |
      <span>
      {{- if .Attributes.Has "prefix"}}{{escape (.Attributes.GetAsString "prefix")}} {{else}}hello {{end -}}
      {{- if ne .Value ""}}{{escape .Value}}{{else}}world{{- end -}}
      {{- escape (.Attributes.GetAsString "suffix") -}}
      </span>
    -block: |
      <div class="helloblock">
      <div class="content">
      <span>
      {{- if .Attributes.Has "prefix"}}{{escape (.Attributes.GetAsString "prefix")}} {{else}}hello {{end -}}
      {{- if ne .Value ""}}{{escape .Value}}{{else}}world{{- end -}}
      {{- escape (.Attributes.GetAsString "suffix") -}}
      </span>
      </div>
      </div>

See discussion on https://github.com/bytesparadise/libasciidoc/issues/334#issuecomment-491790437

[Arteneko]

I think that being format-independent would be a wise idea.

For this need, we could use a library like the well-known viper one.

[xcoulon]

I think that being format-independent would be a wise idea.

For this need, we could use a library like the well-known viper one.

Good point, @IvanDelsinne The example above was an example of config file where there's a template defined for inline and block usage of a custom macro. I believe that YAML is a suitable format for this kind of configuration, but being agnostic is a plus for the users, of course.

[gdamore]

Could this be a way to get to semantic markup? Or maybe ebook output ?

[xcoulon]

@Arteneko I'm moving this issue to the next milestone unless it's something you need earlier?

[xcoulon]

Could this be a way to get to semantic markup? Or maybe ebook output ?

@gdamore could you elaborate on this, please?

[gdamore]

If we can supply different markup for different elements then perhaps we can generate true semantic HTML5. I believe the ebook formats are using semantic markup as well along with some extra metadata and wrapping.

Meaning that giving access to these templates may lead to expanding the capabilities of libasciidoc to cover other use cases and output formats.

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Xavier Coulon [email protected] Sent: Saturday, March 14, 2020 12:52:04 AM To: bytesparadise/libasciidoc [email protected] Cc: gdamore [email protected]; Mention [email protected] Subject: Re: [bytesparadise/libasciidoc] Use a config file to specify custom templates (#349)

Could this be a way to get to semantic markup? Or maybe ebook output ?

@gdamorehttps://github.com/gdamore could you elaborate on this, please?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/bytesparadise/libasciidoc/issues/349#issuecomment-599024358, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAJ4G7MI6IRBIA2QNV4GZBLRHMZSJANCNFSM4HMPDZEQ.

[gdamore]

I'm starting to think more about this -- I've been using asciidoctorj to format epub3 documents lately, and I wind up doing a lot of both pre- and post- processing to workround the limitations . Plus, asciidoctorj is horribly slow.

What would be nice would be able to use this to generate semantic XHTML markup (perhaps with a bit more flexibility), which could then extended to create true epub3 documents.

I know this isn't your mission (focused as you are on hugo), but for me this would be a very nice win.

[Arteneko]

Coming here after a while, I just wanted to add my 2c from the original issue about YAML, which I think is pretty unsuited, hard to use, impractical, and slow.

[xcoulon]

hello @Arteneko 👋

I have not taken time to think more about this issue. Thanks for your feedback with regards to YAML, I'll try to see if there's a better solution ;)

[gdamore]

I have thought a bit about this... I think this is in line with the other stuff we had been talking about. Basically once we split out the templatized renderer from the templates themselves, this can be instantiated as a file-driven loader I think.

[xcoulon]

I have thought a bit about this... I think this is in line with the other stuff we had been talking about. Basically once we split out the templatized renderer from the templates themselves, this can be instantiated as a file-driven loader I think.

yes, that would be probably easier, indeed.

[gdamore]

I'd recommend punting this out of the v0.5.0 milestone. Not because it's terrifically hard, but because I'm worried that the templates we have today are still not yet stabilized, and we probably want to take some care before we expose them to end users -- I think breaking changes are coming soon.

I also think there is so much good stuff in v0.5.0 right now that I'd rather not hold v0.5.0 back while waiting for this.

[xcoulon]

ok, let's move this issue out of the milestone scope, then