Possible way to include some shorthand helpers or utils.

[iamkarshe]

For example to include view from template folder, one can directly use util. function.

<?= view('_shared/header',  ['title' => "My App"]); ?>
<?= view('_shared/sidebar', []); ?>

I have implemented something like about using —

function view($ctx, $data_array = [])
{
  $fs_path = sprintf("%s/%s/%s.php", realpath(__DIR__), 'views', $ctx);
  foreach ($data_array as $key => $value) {
    $$key = $value;
  }
  include($fs_path);
}

[iamkarshe]

Some helpful utility functions could be —

1. CSRF token generator
2. Caching page
3. Cookie
4. Session
5. Validation

Few of the helpers I've extended from third-party packages.

Sessions Management Utilities

function set_session_value($key, $value)
{
  global $session;
  return $session->set($key, $value);
}

function pull_session_value($key)
{
  global $session;
  return $session->pull($key);
}

function remove_session_value($key)
{
  global $session;
  return $session->remove($key);
}

function destroy_session()
{
  global $session;
  return $session->clear();
}

Package used: josantonius/session

use Josantonius\Session\Session;

$session = new Session();
$session->start([
  'name' => "my_app",
  'cookie_httponly' => true,
]);

Likewise, I am currently using DB (using MeekroDB) —

function register_db_instance()
{
  // MeekroDB for MySQL-PDO Connection
  Flight::register('db', 'MeekroDB', [
    $_ENV['DB_HOST'],
    $_ENV['DB_USER'],
    $_ENV['DB_PASSWORD'],
    $_ENV['DB_NAME'],
    null,
    'utf8',
  ]);
}

And, later defined helper functions for my DB-usages as:

function get_item_from_db($table, $slug)
{
  $db = Flight::db();
  $query = sprintf("SELECT * FROM %s WHERE slug=%%s;", $table);
  $item = $db->queryFirstRow($query, $slug);
  return $item;
}

[n0nag0n]

For example to include view from template folder, one can directly use util. function.

For templates specifically.....I'm kinda not a fan of the implementation that flight has cause it's.....super limited. I would HIGHLY recommend something like Latte (my fav) or Twig if you want a real hardcore (and secure!) templating framework. Since Flight is really just a basic router "with some flare" adding a full templating system is overkill.

As for the other things you mention I believe what you're after is containerization which Flight has built in (in a weird way). In most frameworks you do something like $db = Container::get('db'); so you can share the same instance of db. How you would implement the container in flight is just like how you did it for your db instance with Flight::db(); You would just do the same with Flight::session(), Flight::cache(), etc.

If you go the object oriented way, you'd just do $Engine->cache() for instance after you register it.

[iamkarshe]

Latte is amazing! https://latte.nette.org/en/

[n0nag0n]

I agree, I use it in ALL my projects. Super intuitive, fast, and feels good!

[fadrian06]

What do you think about a dependency injection container?

[n0nag0n]

What do you think about a dependency injection container?

Flight technically already has one. When you do Flight::register() and then Flight::myMethod() that's technically a container.

[fadrian06]

yes but what if a controller uses composition over inheritance and receives its dependency. I don't know how many ways there are to solve this problem but with DI-Container it would be solved

[n0nag0n]

Maybe an example might help? I think you could still do Flight::db() in your controller.

[bvfbarten]

This is an old topic, at the time I was against it as I saw psr7 an unnecessary overhead that other frameworks were using. However, an adapter for flight would allow it to easily use swoole or road runner along with the many psr7 compliant middlewares out there. @n0nag0n why did you stop using fatfree framework?

[n0nag0n]

Yeah I see your point. We have a discussion going on about that currently here.

The thing with PSR7 is that just by having it, doesn't mean it will work with Swoole and such. It is a step in the right direction though. The thing that concerns me is that there are some core pieces that will need to be disassembled and reconnected a different way in order for us to truly be compatible with async frameworks. Thank goodness for the 100% unit test coverage but I'm confident there's use cases of the core that aren't covered in those unit tests and we'll break backwards compatibility for folks. It's a complex situation :)

As for leaving Fat-Free, I haven't left Fat-Free. Still have a few projects where Fat-Free is the core of the project. There's just a few things that I've wanted to change about Fat-Free and it's hard to make changes on a project that's not well unit tested and also doesn't have the proper licensing in place. There's also a few fundamental flaws in place that are kind of annoying to work around. But overall I'm very thankful for Fat-Free. It really helped me get do understand centralized routing and the importance of good code structure (given loose guidelines). I also liked that the codebase was simple enough that I could dive in and try to figure things out. Flight though I feel takes that to the next level. There were a few major features I felt were lacking and I feel now with where Flight is (with the active record libary now) it is a framework I can do a lot of good damage with on projects!

[n0nag0n]

Feels like most of what's going on in here is resolved in the other discussion or will be addressed at some point (real containers). As for the view parts, Latte may be the best choice as it's best to keep your templates as "dumb" as possible without injection globals or outside services into your templates.

[n0nag0n]

FYI, a DIC is now part of Flight https://docs.flightphp.com/learn/dependency-injection-container