view support

[the-moisrex]

Adding initial ctx.view("file.mustache") support.

View Manager Features:

• [x] Auto cache: only-in-memory cache the parsed views
• [ ] Data passing: should understand different data types including:
  • [ ] JSON
  • [ ] Standard Collections: std::array | std::vector | list | ...
  • [ ] lexically convertible to strings (int, string, string_view, double, ...)
  • [ ] objects with .render() method
• [ ] Data Conversion: convert the data types to match what the view needs
• [ ] Data Provider File: .dp.cpp file (a c++20 module?)
• [x] Path pool: View files directory roots
• [ ] SubView: importing a view from another view
• [ ] Cross-Sub-Viewing: importing a view of format B inside view of format A(e.g.: include a json from a mustache)
• [ ] Extension support
  • [ ] Add support for more formats
• [x] Move the view into the http directory or separate the concept of "context" from "views"
• [ ] #165

Possible Views:

• [x] json
• [ ] json-cpp: A json file with C++-like features
• [x] mustache (#101)
• [ ] VML (our custom language)
• [ ] pug
• [ ] Laravel's Blade
• [x] #121

[the-moisrex]

Caching

We need to finish caching system (#91) before we can start implementing a good view system.

lru_cache with memory_gate seems a good choice for caching parsed data.

possible implementations:

1. Pass the cache from above,
2. Create the cache inside the view-manager.

Either way, the lru_cache requires a bit of configuration, so we're not gonna let the user configure this by default but we do want them to be able to.

[the-moisrex]

Data Conversion

Where should the data conversion happen?

1. inside view
2. inside view manager
3. inside view manager but customized for that specific view
4. Inside view manager and pass the view manager to the view
5. Inside view manager the conversion happens, inside data_view, conversion to the view's necessary types happen.

Inside the view means code duplication

[the-moisrex]

Where should view_manager be used?

1. In the context
2. In the server/protocol
3. In the application
4. In the request
5. Call applications with a context and not request

In the context, it wouldn't be able to cache the parsed files unless with a few tricks that I don't like. Context is router specific thing. The user may want to use another type of router.

In the server/protocol, it can be stored for a long running process. But it's not that straight forward to pass it to the application. There are multiple ways we can achieve this but it'll complicate the things that the user needs to do in order to use it.

In the application, everything seems okay, but the problem is that the user has to manage its life time and that'll complicate things for the user.

The request needs to stay a request, it doesn't make sense for a request to contain a view.

Calling application with a context will probably save the whole issue; at this point, I'm not sure why I designed the routing system this way; I should check this more...