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