Htmlact a206fe6

Manuals

The manual explains it all.

Library htmlact

That's not strictly needed. Only useful if you use Webs and Htmlit.

• Htmlact Htmlit HTML generation and Webs HTTP headers.

Library htmlact.page

That's not srictly needed either. Only useful if you already js_of_ocaml based front-end code and want to bundle the page driver with it. You can instead simply add the $(opam var htmlact:share)/htmlact-page.js script to your webpages

• Htmlact_page htmlact webpage driver.

Quick start

If you really do not want to write a single line of front-end code, include the page $(opam var htmlact:share)/htmlact-page.js in your page. Now the following:

<script type="text/javascript" defer src="htmlact-page.js"></script>
<button data-request="POST /clicked"
        data-effect="element">Replace me</button>

instructs a click on the button to perform a POST request to /clicked and replace the button with the HTML response. That's it.

If you installed htmlact with tests (opam install -t htmlact). The htamlact-examples binary serves a few interaction examples and links to their sources.

The manual has all the details.

TODO

• Review animation interaction for htmlact-in, it's not so good to have transition on bare elements which are triggered according to .htmlact-in -> bare
• Provide and trigger events for Htmlact behaviour itself, this allows to chain Htmlact connections in interesting ways and helps coordinating with other front end code. Update. Something was hastily added in Htmlact.Ev. needs proper design and documentation.
• Because of resource costs we likely want something like multi-target response updates for SSE and websockets. Also useful for deletion examples (or should we enrich effect ?)
• Provide support for full page target. Support a data-preserve attribute which patches by id in the replacement
• Provide support history via data-push-history, pushes the request url, snapshots body element for state restoration.
• Provide support for load and revealed events.
• The event source mecanism remains expressively limited e.g. for click event from that element, key from that other one, but maybe we don't care. It's possible to work around. Parsewise it's difficult to have a <sel> argument in an attribute beyond itself (e.g. from:<sel>).
• Define the semantics in case of HTTP errors
• Maybe for keep event simple, only trigger on request element but devise a separate DSL to declare custom events and fan-in from other events. Or even, let that to separate JavaScript fiddling.
• Consider data-response-sel to apply on the response.
• Provide request counters and discard if older reponse or not latest.
• Provide default filters that easily
• Provide focus and scroll position management.
• Sometimes it feels a bit stupid to have a trip to the server. Provide local substitution.
• We likely want to expose the dom effecting stuff (for now exposed hastily for hyperbib and undocumented), make a nice api and let htmlact use it.
• Support for header specification ?