Considering moving captive portal page to a template in SPIFFS

[hillct]

Is there a design goal that precludes taking advantage of the built-in template engine in ESPAsyncWebServer to store and server the captive portal template content from SPIFFS? I ask this before I undertake to do so, in case there are compelling reasons not to do so. While my first thought was for dependencies, it seems all those dependencies (fs.h and hardware that supports SPIFFS, I guess) are baked into ESPAsyncWebServer already, so that shouldn't play into it. Are there other considerations I'm overlooking?

The obvious advantage to serving that content out of SPIFFS, is the ability to highly customize the portal appearance without need to modify the library directly.

[alanswx]

I don’t think the templating system existed when I wrote this library. Sounds like a great idea. Do you want to take a pass at it and submit a pull request? I won’t have time to look at it for a few weeks.

[hillct]

I have one other project ahead of this in the queue, but I'll be able to take a look at that migration, thereafter.

[alanswx]

I wonder if we should either add a new method or fail back if the template isn’t on the spiffs.

[gcopeland]

I'd prefer conditional if that route is taken. Would be nice to compile the library without the template overhead and strictly rely upon SPIFFS content. Accordingly, if you have a device which expects content on SPIFFS and its not available, this is a bug with the application. Meaning the SPIFFS files have not been provided to the device. IMOHO, the correct solution is to uploadfs rather than fallback with an improperly burned device.

By allowing a conditional default to include everything in the library, it makes it newbie friendly. As I wouldn't expect many to know about uploadfs type options. But for the more advanced, there isn't a legit reason to needlessly carry the extra burden on the device.

[alanswx]

If someone wants to contribute this, it would be great.