ESP8266 Community Forum

Hi!

So creating some AJAX HTML controls is no arcane magic, but did you ever wish you wouldn't have to worry about all the little details of synchronizing your data back and forth? I know I have, and so I decided to create a library to make creating basic web controls / displays easy: https://github.com/tfry-git/EmbAJAX . It's still pretty fresh, but personally, I find it quite useful, already. Licence LGPL 3+.

Core features:

Ability to "print" common controls to an HTML page (checkboxes, radio buttons, push buttons, drop-down selectors, text input, color selection, sliders, text display, connection status indicator)

Automatic addition of AJAX code to relay control information from the client to the server and back

Automatic handling of the AJAX requests on the server side

Object-based representation of the controls on the web page. The programmer can simply interact with local objects, while the framework takes care of keeping information in sync with the client.

Allows multiple clients to interact with the same page, concurrently, and keeps controls in sync across clients.

Supports arbitrary number of pages, and elements can be shared across pages.

Simple but effective error handling for unreliable connections and server reboots

There's also API documentation (https://tfry-git.github.io/EmbAJAX/api/annotated.html), some basic examples, and an introductory "instructable" (http://www.instructables.com/id/Easy-ESP8266-Arduino-Core-Web-Controls-With-EmbAJA/).

I hope it will be of use to some of you, too!

Looks cool. I will definitely try it.
Is the html code created by MAKE_EmbAJAXPage static? I do ask this because it appears to me that serving webpages using print's in the C++ code seems to be limited to fairly simple pages. Instead I am looking for a way to copy the create code snippets for the controls and paste them into existing complex html files.
Any thoughts in that direction?
Thanks!

Yes and no. Currently, the list of elements inside an EmbAJAXPage is fixed (because I wanted to avoid dynamic allocations as much as possible). However, dynamic lists of elements could certainly be added. The content of the page is "rendered" fresh, everytime a new client connects, so it is dynamic in this respect.

All existing building blocks are essentially fixed, but you can customize them by overriding the "print()"-method in a child class. In your case, you would probably want to subclass EmbAJAXContainer, customizing print() to build your page any way you want. Add all your controls to an instance of your subclass, and add that as the only child of an EmbAJAXPage. Then the framework will take care of all data synchronization, but you are completely free to do whatever you want inside print(), including serving the full page from file. See the "Visibility" example for how to organize elements inside an EmbAJAXContainer. In addition to the code for the controls, themselves, you'd need to make sure to include the (short) AJAX handling script in the page header.

I admit that does not sound terribly elegant, just trying to explain what's currently possible. I suppose what you're looking for is more along the lines of serving a page from a template, where some special markup like <EMBAJAX id="xyz"/> would be replaced with the corresponding element code, dynamically. Well, that's not there, yet, but the framework is flexible enough to allow implementing that.

Re-read your question, and realized that I seem to have gotten you all wrong. If I understand you right, now, you essentially _want_ to serve a static page? No problem:

[list=]Generate a page with the controls you need the usual way[/list]
[list=]Browse that, and copy the generated HTML source code in your browser[/list]
[list=]Edit the HTML to your liking. Just make sure to keep the AJAX support script in the page header intact[/list]
[list=]In your page handler (server.on("/whereever")), replace the call to EmbAJAXPage::print() with code to send your static/cached/edited page, instead.[/list]

That should be all you need. EmbAJAX will never know the difference, as long as the Javascripts are intact (and the ids of the controls are kept the same as those defined in the sketch).