format support for webui_run and webui_script

[konakona418]

No description provided.

[konakona418]

Implementation of the formatting feature proposed in #677.

Added two functions webui_run_fmt and webui_script_fmt, and their C++ wrapper. The two functions use vsnprintf to format strings, then call webui_run and webui_script respectively.

However there are still a few concerns:

Among all, security issues, especially when escape chars are present.

And for C++ wrapper, I used template argument pack, which might have some compatibility issues. I wonder if a C++ wrapper for this is really necessary, as there are already some nice formatting utils (like fmtlib)

[AlbertShown]

Implementation of the formatting feature proposed in #677

Yes, I saw it, and was just thinking if those APIs may break wrappers that use automated-scripts/AI to generate code.

Added two functions webui_run_fmt and webui_script_fmt

Those new APIs are handy and very useful, the only challenge is that almost all wrappers can't use them, and C++ doesn't need them, and the escape chars may break them.

[AlbertShown]

Options we have:

1. Marge PR, and let all wrappers know that they should ignore those APIs (not recommended)
2. Add those functions to C examples directly
3. Create a new header file webui_extras.h that have all the C/C++ only APIs

[konakona418]

Hi @AlbertShown,

Thanks for the quick feedback! The variadic functions are indeed pretty annoying to handle...

I agree that the 3rd option (webui_extras.h) is the best path forward, as there won't be FFI-related concerns, and developers can include whenever it's necessary. Perhaps some other future util functions can be put into this file as well.

I'll make this PR a draft and work on it.

[konakona418]

I just split the declarations to a webui_extras.h. The definitions are still in webui.c.

[AlbertShown]

Thank you @konakona418, but for optimization purposes I suggest this:

1. removing #include "webui.h" from webui_extras.h as we expect user will include webui.h + webui_extras.h
2. adding #define WEBUI_EXTRAS_API inside webui_extras.h, and wrap webui_run_fmt() inside webui.c so if user didn't include webui_extras.h no webui_extras.h will be compiled for optimization purposes (regardless compiler used optimize flags)
3. Also I think webui_extensions.h is more common than webui_extras.h

[konakona418]

Thanks @AlbertShown,

I've refactored the PR according to your suggestions:

• Renamed the header to webui_extensions.h;
• Removed the webui.h dependency;
• Added the WEBUI_EXTENSION_API macro with documentation on how to activate the implementation.

And few technical notes on the implementation:

• To ensure WEBUI_EXPORT is recognized, I've added a preprocessor check that expects webui.h to be included before webui_extensions.h;
• If webui.c is compiled as a separate translation unit, developers should define WEBUI_EXTENSIONS_API in their compiler settings to "activate" the logic.

[konakona418]

Sorry there was a typo in my last commit, and there's possibility where macro redefinition might occur...
I was using CMake and wrote the definition in the cmake configuration, didn't notice that...
Just fixed it.

[konakona418]

And as for the escape chars problem, I guess maybe there could be "safe" variations of the two functions, which have some overhead, but handles chars like quotes and backslashes internally?

But the major problem for this is that there can be a lot of corner cases, and a function covering all these cases could be non-trivial to implement and maintain due to the JS string literal rules. e.g., single quotes ', double quotes ", and backticks ` each have different escaping strategies.

The current implementation provides a balance for common use cases where no complex strings are involved. And as long as we make the risks clear in the documentation, developers can decide whether to go with this function or use a more verbose formatter implementation.

If we feel it's necessary in the future, we could potentially add something like webui_escape_js_string() in webui_extensions.h later, rather than baking all that logic into the formatting functions themselves

[AlbertShown]

While testing it I found some issue with dynamic examples, so I'm working on an alternative approach.

[AlbertShown]

I tried to make extensions being compiled inside WebUI library, both static and dynamic, but this will need updating all makefiles to include WEBUI_EXTENSIONS macros, which will force some wrappers like Zig and Nim, V, and other to update their compiling scripts as well... too much headache.

Another solution is to simply make those functions always compiled in library, both static and dynamic, but exported in webui_extensions.h, easy, but not optimized. We saw some people use WebUI inside small devices and embedded systems, so we plan to add WEBUI_NO_WEBVIEW to make WebUI even more optimized and smaller in future, so, optimization is important.

Therefore, I suggest to make all extensions code outside WebUI, and simply add it directly in webui_extensions.h so it will be compiled at application level not library level.

[App] --> [webui.h] --> [WebUI Library]
[App] --> [webui_extensions.h] --> [webui.h] --> [WebUI Library]

@konakona418 What do you think?

[konakona418]

Hi @AlbertShown,

Thank you for the explanation!

This sounds reasonable to me, as extensions should have as little side effects to the core functionalities as possible. Making the extension header-only is a brilliant way to achieve this, as it avoids forcing all language wrappers to update their build logic.

Since you have a clear vision for the optimization and the overall extension architecture, please feel free to take it from here. I'm excited to see this feature integrated in a way that best fits the project's long-term roadmap!

[AlbertShown]

Already done 7d22079

Thank you @konakona418 for the extensions idea, now it's integrated in the WebUI.
We will look into the escape chars issue in the future.