A time-lapse that will require a 10 more time-lapses just undo what I was trying to do!

I'm re-designing the whole idea of valves in the project. The final result will have more power than the current idea of valves in the webpp project.

Developing broken ideas!
New ideas are coming for the routing system.

The new routing system:

Problems this system will solve compared to the valving system:
- The migrations now can access the context
Previously it was possible to implement this through some ways but
the problem was that the whole thing was based on requests and
responses, which meant that we couldn't pass other objects and types
without modifying the request and response types which adding a new
parameter into their template parameter lists only introduced more
complexity for the library users
Other ways we could've solved this issue:
- Using virtual inheritance for requests
Would've added unnecessary indirection
- Using self made vtable
Would've added unnecessary indirection
- Using void* type or similar ones and cast them later
Would've added unnecessary indirection
- Passing a context object to the migrations/valves to solve this
Which would've introduced complexity because at that point the
requests and the responses were not retrievable from the context.

- The valves are not aware of the requests and other details provided
by the context.
Previously this was an issue since the valves were only capable of
checking if the request is a match for the valve or not and they
couldn't modify the response or even stop the request or provide
information for the migration.

- A better constexpr way of passing valves and migrations to the router
Since the valves and the migrations were a separate entities which
they would become one entity after creating the "route" template
class, it was a problem to create a nicer looking route by the user.

- Using valves as validators and validators as valves.
Using valves as validators are now easier since the user doesn't have
to create a constexpr variable and use that variable in both the
.on method on router and inside the migration.
Now the whole thing is inside the context, and it'll be passed to the
valves/migrations by reference.
Of course using validators as valves require a bit of a hack from the
user but there's just no other way and honestly it's easy enough to
do so!


Route types:
- Entry routes
- Sub routes

Definitions:
- Route: Possible ways that are capable of handling user requests
- Entry Route: The main routes that will be checked first
- Sub Route: The routes belong to the each Entry Routes
- Context: An object of arbitrary type that will contain everything
that routes will need including:
- Request
- Response
- Previous entry routes context changes
- Previous sub routes context changes
- Original entry routes level context
- Original sub routes context changes


Features we need:
- [ ] Extendable entry and sub routes
- [ ] Use class operator() as a place to add more sub-routes
- [ ] Having access to the context class in the callables
- [ ] Having access to the request and the response
- [ ] Termination of continuation of checking the sub-routes by parents
- [ ] Termination of continuation of checking the entry-routes by any
previous routes, or sub-routes.
- [ ] Context modification
- [ ] Sub-Route local context modification by any previous sub-routes
- [ ] Inter-Entry-Route context modification by any previous
(sub/entry) routes
- [ ] Entry-Route prioritization
- [ ] Auto prioritization
- [ ] Manual prioritization
- [ ] Hinted prioritization
- [ ] On-The-Fly Re-Prioritization
- [ ] Dynamic route generation / Dynamic route switching


Usage examples:
- .on(get and "/about"_path >> about_page)
- ( get and "/home"_path ) or ( post && "/home/{page}"_tpath ) >> ...
- opath() /"home" / integer("page") /
- empty / action_list("action", {"open", "delete"}) >> []{...}
- (...) >> &non_templated_class_with_templated_callable_operator
- get and "/profile/"_tpath and set_by_class_constructor

I'm gonna call this a different name though. Strategy pattern doesn't suits it.
Any of these represents the intent more efficiently:
- Parsed value generation pattern
- Data passing pattern
- Data controlling flow
- Context passing

I like the Context Passing since it matches with the above routing system I'm about to design.

Let me know in the @webpp_discuss group if you have a better name for it.

You can find another one hour and half video of me working on the project here:
https://www.aparat.com/v/gay0q

First stages of implementing the new routing system idea.

Full video: https://www.aparat.com/v/8Rvcj

4hours of me working on this project:

https://www.aparat.com/v/wAGx3

I just found out that I've been mistakenly recording the live coding video with this image on top of everything. 😂

@webpp

I find happiness in finding bugs in IDEs. 🤣

https://twitter.com/the_moisrex/status/1257796596726726658?s=20

Let's see how much time it will take CLion to fix it 😁
The tweet!

I need to write something like this for every type I introduce in the framework. See compiler developers? I need C++20's "concepts" now!

If you know a way I can use them fully, please say so in the @webpp_discuss. Thanks.

Oh, would you look at that! Clang 10 supports it and GCC 9.3.0 needs -fconcepts to work.

I need some macro magic to use these in the CMake and also in the project fully.

Well not in my project you don't! 😂

Seems like GCC 9.3.0 with -fconcepts is no good. There's a bug.
I haven't tested the new version 10 that came out today which doesn't need the -fconcepts though.

Clang 10.0.0 works fine though.

GCC 10.1.0 works just fine.
https://godbolt.org/z/7Z7cWh