-
-
Save mausch/7706117 to your computer and use it in GitHub Desktop.
// https://twitter.com/mausch/status/406420573518970880 | |
// compiles to ModelLayout -> XElement where ModelLayout = { title: string; script: XAttribute; bodyAttrs: XAttribute list; body: XElement } | |
type Layout = HTML<""" | |
<html> | |
<head> | |
<title><x:text id="title"/></title> | |
<script x:attr="script"></script> | |
</head> | |
<body x:attrs="bodyAttrs"> | |
<x:elem id="body"/> | |
</body> | |
</html> | |
"""> |
Do you need the different replacement symbols? How many were you thinking?
Good point: if there is a doctype, it has to compile to a XDocument.
No idea what a generated form of Wing Beats would look like.
Updated to make it simpler to parse and implement.
Other than the ones shown, I would also include XElement list.
A variant of this would also be useful as a poor-man's macro for formlets.
Goal should be that I could take a layout from a designer and use it almost directly. This introduces a lot of new syntax.
I don't see any new syntax here. It's just HTML with some attributes/elements in a different namespace. You can take a layout from a designer directly (which would compile to a XElement or XDocument), then start adding holes for composition.
I see. That's not bad. What about using data- attributes or {{...}} bindings?
Also, I like the idea of using a Render function that takes an instance of the model.
I just saw your comment about formlets. That is an interesting idea. Sort of like Yesod's widgets?
But data-xxx attributes are valid, regular HTML, so they can't be used for server-side templating. The templating syntax has to be completely lifted. {{...}}
can also be regular text and can't differentiate text from a single element from multiple elements, make it harder to parse/implement, would need an escaping mechanism, and I thought you wanted to avoid special syntax :)
Yesod widgets are more about componentization, i.e. bundling HTML+CSS+JS, declaring dependencies, and making such bundles safely composable. It's a separate, orthogonal task.
My reference to formlets was aimed at implementing some poor-man's form of Links formlets sugar (example). I say "poor-man's" because you need full-blown macros to implement this properly (IIRC the original formlets implementation used camlp4 for such sugar).
Hey, I had a similar idea a while ago and wrote a HTML parser to start this but never got the chance to actually lift it into a type provider. Have a look a this.. FSharpEnt Html maybe a starting point. I was thinking of just being able to replace elements directly via the type provider using the DOM module provided or maybe some HTML builder via a computation expression.. Just thinking out loud really..
@colinbull that is where I would really like to end up.
@mausch I misspoke. I'm not opposed to new syntax. I meant to question the use of additional namespaces. That is rather uncommon now. I was happy with the additional symbols, so long as they are known or easily findable. I was also wondering whether multiple were needed or whether one might work with a bit more contextual inference.
I realized that what I actually want is XML literals. I really don't care about non-XML HTML so I just use the System.Xml.Linq parser. I just started implementing it here: https://github.com/mausch/XmlLiteralsTypeProvider
After implementing holes for elements/attributes, it would be very interesting to be able to read templates from a file. That way, you'd keep templates in a file, which anyone could edit outside of a development environment but any changes to its holes would affect compilation as it should.
Would XElement still work if you add the doctype? What if you use HTML5 and not XHTML5?
Otherwise, that is what I was thinking, too.
Also, do you like this better than a generated form of Wing Beats?