Enhance AsyncCallbackJsonWebHandler with regex support

[nicola02nb]

Added regex support for URI handling in AsyncCallbackJsonWebHandler like in AsyncCallbackWebHandler.

With this you can do something like that

auto *pageHandler = new AsyncCallbackJsonWebHandler("^\\/page\\/(\\d+)$",
    [](AsyncWebServerRequest *request, JsonVariant &json) {
        String number = request->pathArg(0);
    });
server->addHandler(pageHandler);

And also have the already parsed json body

[mathieucarbou]

@nicola02nb : is your pr a work in progress ? I have moved the pr to draft since I am not sure.

thanks for the contribution this is a good idea !

also could you please add an example of you have time ?

[nicola02nb]

is your pr a work in progress ?

I made those edits on my local project and worked so I thought to make a pr for that(I copy pasted the code from AsyncCallbackWebHandler)

I have moved the pr to draft since I am not sure.

No prob

thanks for the contribution this is a good idea !

Happy to hear that

also could you please add an example of you have time ?

Yeah, give me some time and I'll do that

[mathieucarbou]

Thanks 👍

[nicola02nb]

@mathieucarbou should be all done, please let me know if everithing is ok

[mathieucarbou]

@nicola02nb thanks!

I will talk to the team about this one.

I finished a refactoring of the Json support in #301, following isseu #300 .

This lead me think that now that using a Json based handler is the same as other methods, this regex parsing could also be applied to any URI, not only for the Json callback... So I am wondering if this code should instead be moved in the request processor, way before handlers are called, when parameters are parsed.

~~There is already a mechanism in place (see the doc) to support variables in paths. ~~

So maybe extending this place would be an option.

@willmmiles @me-no-dev : we need to talk about this.

[mathieucarbou]

@nicola02nb thanks!

I will talk to the team about this one.

I finished a refactoring of the Json support in #301, following isseu #300 .

This lead me think that now that using a Json based handler is the same as other methods, this regex parsing could also be applied to any URI, not only for the Json callback... So I am wondering if this code should instead be moved in the request processor, way before handlers are called, when parameters are parsed.

~~There is already a mechanism in place (see the doc) to support variables in paths. ~~

So maybe extending this place would be an option.

@willmmiles @me-no-dev : we need to talk about this.

Update:

Ah! Looking again at the code I see that the regex check is done in AsyncCallbackWebHandler::canHandle and you simply copy pasted the same code so that it also applies to AsyncCallbackJsonWebHandler::canHandle.

So yes that's good no worry! I forgot how regex was wired ;-)

Let's wait for the refactoring into #301 to be merged first and then rebase these changes.

You should be also able to update you example to use the new way of adding a json handler, just by using:

server.on("^\\/page\\/(\\d+)$", HTTP_POST, [](AsyncWebServerRequest *request, JsonVariant &json) {
    // handle the json POST/PUT request...
    String number = request->pathArg(0);
});

[nicola02nb]

Let's wait for the refactoring into #301 to be merged first and then rebase these changes.

Great, so I can just close this pr and wait, right?

[mathieucarbou]

Let's wait for the refactoring into #301 to be merged first and then rebase these changes.

Great, so I can just close this pr and wait, right?

No no!
Please keep it open.
We / you would need to rebase it on top of main soon. The regex changes are OK but only in this PR ;-)
And also update the example to fit the new API.

I see that your branch is opened to maintainers to either you or us will be able to do these updates.

[nicola02nb]

No no!
Please keep it open.

Okok, my bad sorry, thought you will get it work directly in #301

And also update the example to fit the new API.

Of course :)

[mathieucarbou]

@nicola02nb : FYI we discussed this PR with the team and we will implement it but another way.

To avoid the code duplication, we will introduce a URIMatcher class, matching the path, but also supporting regex. And we will modify all the on() methods to support a URIMatcher instead of a char* for the path. This can be done in a backward compatible way.

This way, the logic will be at one place and applied to all handlers. even those serving static content and templates.

You can keep this PR opened: either we will build on it, or at least refer to it.

Thanks!

[nicola02nb]

Ok cool, I'll keep it open so you can work on it if you want... are you going to add it soon? Just to have an idea....

[mathieucarbou]

Yes, probably this week or next week.
I would like to have it done asap because we need to do a release : there are many fixes waiting in main.

[mathieucarbou]

@nicola02nb : FYI I have raised a work in progress PR which is compiling but not tested yet and no regex examples yet.
But if you have the curiosity to test it, you could swap your dependency to the urimatcher branch:

lib_deps = https://github.com/ESP32Async/ESPAsyncWebServer#urimatcher

You do not need any code change, still need to set the macro ASYNCWEBSERVER_REGEX.
If your uri passed in the handlers start with ^ and end with $ then the uri is detected as a pattern.

PR: #304

[nicola02nb]

FYI I have raised a work in progress PR which is compiling but not tested yet and no regex examples yet.
But if you have the curiosity to test it, you could swap your dependency to the urimatcher branch:

Just tried on my project and works fine with no issue atm

lib_deps = https://github.com/ESP32Async/ESPAsyncWebServer#urimatcher

That's clever didn't know about that, thanks

[nicola02nb]

Closing in favour of #304