1. 44
  1.  

  2. 3

    HTML rewriting is my preferred method of “templating” HTML I wrote a, no unmaintained, library for it in Go: https://bitbucket.org/zaphar/go-html-transform/src/default/. I find it to have a longer learning curve but a superior and safer way than templating to dynamically generate html.

    1. 6

      Every language needs at least one I think. The only alternative is XSLT, which is even harder to learn, and HTML5 is not a valid XML.

      A library that can produce a typed tree in the style of TyXML or Ur/Web would be even more intriguing.

    2. 3

      Using the DOM has been my preferred method of any kind of html “template” stuff for a long time now - ever since I wrote my server-side dom library (in D; https://github.com/adamdruppe/arsd/blob/master/dom.d ) I’ve actually come to like the possibilities a lot.

      I recently formalized some of it as a separate library too ( https://github.com/adamdruppe/arsd/blob/master/webtemplate.d )… but i haven’t released the documentation yet. To give you an idea though, you do stuff like this:

      skeleton.html:

      <!DOCTYPE html>
      <html>
      <head></head>
      <body><main></main></body>
      </html>
      

      mytemplate.html:

      <main>
      	<p>This is my <%= name %> template.</p>
      	<for-each over="items" as="item">
      		<%= item.value %>
      	</for-each>
      </main>
      

      And any unique tags found in the template are used to replace the corresponding element in the skeleton. So here, <main> is a unique element (per spec, there is only supposed to be one per page, also true of title, html, body head, and IDs) so the one from the template is pasted into the one from the skeleton.

      Then there’s some traditional looking <%= stuff %> and a <for-each> tag, but notice these are actually in the DOM too! This example also didn’t show onrender, which lets you server-side edit the dom of that element right as it is rendering, stuff like adding classes based on script conditions.

      I considered doing some of the configuration selector stuff too, but mine is meant to be used from code, so you’d just call querySelector instead of a config file, so different use case than yours.

      But yeah, I am excited to see more people exploring the possibilities of the DOM! Among the benefits I’ve found:

      1. easy to teach to designers; it is mostly stuff they already are familiar with
      2. it works well without the rest of the app, you can view html files directly too
      3. the server-side DOM ensures all templates are well-formed; good validation and stuff like anti-xss stuff that is harder to do with strings.

      so fun stuff.

      1. 2

        I like your idea of using the DOM directly, also using TOML :)

        1. 2

          Very happy to see this! I think the possibilities with transforming HTML itself are underappreciated.

          1. 1

            How do you see soupault comparing to pollen?

            1. 6

              Pollen looks like a great tool for generating books, I haven’t looked deep into it, but I’m considering it for a book project.

              However, it’s works best for greenfield projects, and you need to convert a project to its way of doing things to make most of it. Soupault’s goal is to work on existing pages, whatever it takes. It’s easy to migrate from another generator or a completely hand-managed site and start hacking your workflow from there (though converting blogs and taxonomies other than section-subsection-subsub… is not quite trivial of course).

            2. 1

              This is my solution for generating static sites: https://adi.tilde.institute/pp/.

              1. 1

                The website certainly looks nice!

                I couldn’t find any reference to atom/rss feeds. I assume this would be handled by an external indexing script, or would this be better done by rewriting of a template feed.xml? If the former, it would be neat to provide an example of a tool that might generate a feed from the index json.

                (Also consider adding a more prominent link to https://github.com/dmbaturin/soupault/? Took me a while to get there while trying to figure out the feed situation.)

                1. 3

                  The docs are pretty much as beta as the program. There’s no built-in Atom/RSS indeed, but an external script can do it. I think it’s better to feed it to an Atom generator library than to modify a template. Also, there’s no global index now, only per-section indices, although an indexing script could work around it by saving the data somewhere so that you can run a feed generator on it after site build.

                  I made an example for generating an HTML index: https://baturin.org/projects/soupault/#using-external-index-generators The fields described in that section are all fields available now, I’m thinking of adding options for custom metadata queries like: {tags = “span.tag”, select_all = true}.

                  1. 12

                    This is a puzzling comment. If you are sharing that generator because you like it, that’s fine, seems simple and lightweight indeed. It will stop working with 4.08 due to mutable strings and camlp4, but it’s easy to fix.

                    However, if you think it’s a similar project, I might have failed to clearly explain what soupault does. USSM is a classic templates + markdown generator—nothing wrong with it, but soupault provides an alternative to that approach. :)