Pondering on a server-side dynamic HTML solution

[Christopher Stevenson]

I've seen a few HTML DSLs around for F#. I'll list a few of them, for reference:

• on F# Snippets: DSL for constructing HTML
• F# to CSS EDSL: Failess
• Websharper Pagelets: http://websharper.com/docs/pagelets

These take after the "Control" pattern for web pages, code defined portions of the screen.

I'm wondering if an F# view engine approach would be a useful alternative. What I'm envisioning is a series of html files with embedded commands (rather like angular.js) that a type provider would interpret, and create two types: a model type, and a function type that transforms an instance of the model to a string (or perhaps an HtmlAgilityPack HTML DOM?), that the webstack can return.

Mulling it over, I would prefer pointing the type provider at the web root folder for the html pages, and have a function that takes a relative filename, and returns the model type and function.

For html reusability, I'm thinking of a particular "data-include" attribute in a containing element which would instruct the type provider to insert the included file. (Much like a partial view in Asp.Net MVC).

Thoughts?

[Adam Granicz]

Just a side-note: WebSharper's *server-side HTML language* (IntelliFactory.Html.*) and the surrounding abstraction for "sites as F# values" are called sitelets, and they are described, arguably in a page that needs many more details, at:

http://websharper.com/docs/sitelets

Sitelets offer a flexible and robust solution to describing client-server applications and come with what we call dynamic templating, e.g. binding to HTML templates with typed placeholders, and instantiating those at runtime.  (WebSharper also supported static templating, where HTML template files were translated to F# code at compile time and used with the rest of the application, but this was removed - see below.) This templating can also be used in client-only applications (without an RPC-based backend).  This particular form of applications can be represented in two main ways:

 * As "offline" sitelets - which generate a full HTML/JS application from an F# sitelet.  One way to create such a sitelet is via the "Sitelet Html Application" Visual Studio template shipped with WebSharper.

 * As a "bundle" application - which enhance an existing HTML base page with dynamic functionality via generated JS and carefully selected entry points.

Pagelets in turn are a mechanism to represent client-side dynamic content and functionality and they use the *client-side HTML language* (IntelliFactory.WebSharper.Html.*).

The latest WebSharper UI library, UI.Next, is a fundamentally different approach to both sitelets and pagelets, and adds reactivity to the mix - enabling to express reactive DOM along with their corresponding model.  UI.Next calls these reactive fragments "documents" and they may very well become the standard HTML language for WebSharper 3.0 for both client and server HTML.  UI.Next documents can encode SPAs, and even some of the capabilities of sitelets (routing, etc.) in a client-side formalism.

We recently started experimenting with adding type providers to bind to external HTML templates for UI.Next consumption, you can find a basic but largely untested approach in the latest Nuget release for UI.Next.  You can expect additional type provider-based capabilities in future releases.

Cheers,

Adam.

--
You received this message because you are subscribed to the Google Groups "F# Web Stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-stack-fs...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Adam Granicz, IntelliFactory
www.intellifactory.com

[Ryan Riley]

This sounds like an idea Mauricio Scheffer and I discussed. He built https://github.com/mausch/XmlLiteralsTypeProvider. I created a project called phazor that I've still not started. I think my intent is closer to yours, but Mauricio's actually exists. :)

---

From: Christopher Stevenson
Sent: ‎10/‎5/‎2014 3:30 AM
To: web-st...@googlegroups.com
Subject: Pondering on a server-side dynamic HTML solution

--

[Mauricio Scheffer]

There's also Wing Beats ( http://wingbeats.codeplex.com/ ) which takes the combinator approach for server-side HTML templates.

As for my project that Ryan mentioned, it's a general type provider to compose XML fragments (which of course also works for HTML as XML). It's not very different conceptually from XML literals in VB.NET (which are also lovely to compose HTML) except that this type provider can read from a file provided at compile-time.

The type provider generates a type with a constructor whose parameters represent the holes in the template. The instantiated object then has a Render() method.

Right now, the project is just a prototype. I haven't continued working on it as I have zero chances of using it in any project (work or OSS) at the moment. Also while I think the idea is cool, actually developing a type provider is not a nice experience, it might be the only non-fun part of writing F# code :-)

--

Mauricio

[Christopher Stevenson]

Yeah, I went through a tutorial on creating a Type Provider, and quickly realized that you need to have a very meta hat on. It is fun watching a Type Provider work like a  Rube Goldberg machine, but putting one together is a feat of engineering. Now that I have a decent grasp of what kind of types Type Providers can create. I think I'll let the idea percolate for a while, until I can put together a detailed plan of how such a type provider could work.

[Ryan Riley]

I learned from Darren that he has an implementation of jinga2 (the templating engine for Python inspired by the one used in Django) in his fss repository. His tests show example usage. If you think you'd like it as a separate resource, you should ask him about separating it into its own NuGet package (if it isn't already).