-
-
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> | |
| """> |
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.
I just saw your comment about formlets. That is an interesting idea. Sort of like Yesod's widgets?