Overview

Most things are stuffed into dashml.core and exposed through the __all__ special object. This is fine, but I can split things out from core into files so it's slightly neater.

Overview

DashML should be able to render non-string types.

How

• Most classes should probably be cast to a string, as a form of "least surprise".
• Boolean attributes should obey HTML5 boolean rules, which means true should keep the attribute and false should remove it.

This will be implemented in core.swap_attributes.

Overview

It would be great to have some docs for DashML. The API is really, really simple, but I could get into a lot more detail than I can in just the README.

Overview

The lxml library doesn't have type definitions, so creating a stub for those would be really helpful. DashML would be completely typed with that addition.

Overview

Right now, DashML provides a render method that outputs a unicode string. This is really portable, but I can make it easier to use DashML in projects by providing "shortcuts" for different frameworks.

We would add a shortcuts module to DashML that contains functions to transform DashML functions into framework-specific HTTP response objects (or whatever the framework uses). Like a render for any given framework.

Potential Features

• Django render helper.
  • Django could even have Django-specific generic views.
• Sanic response.html functions.
• Flask Markup objects for returning HTML.
• Starlette HTMLResponse helper.

Overview

There's no "escape hatch" for DashML- all code goes through the sanitizer so you can't inject html. A solution for this would be an unsafe_from_string method, that converts a string representation of an element into a DashML component.

This is basically going to be a wrapper of lxml.html.fromstring, but in DashML with a scary name to discourage use.