-
-
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> | |
| """> |
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?
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.
Or compile Layout to a class with a method Render that has that ModelLayout -> XElement function, same thing.