[NEW TOOL] fat-free-routes - Generate routes from Php DocBlocks

[richgoldmd]

Hello F3 Community!

I have posted a tool I use in development in several F3 projects that generates the routes from DocBlock comments in the controller classes.

So your controller looks like:

class MyController {


   /**
    *
    * @route GET @alias: /path/to/awesome
    *
    * @param \Base $f3
    * @param array $args
   */
   public function myHandler(\Base $f3, $args) {
      // Do Something fascinating...
   }
}

f3routes will generate a global function which will include, among all of your other routes:

    $f3->route('GET @alias: /path/to/awesome', 'MyController->myHandler');

It supports all of the route parameters (e.g. ttl, kbps), tokens, and maps as well as allowing a base path to be set at the class level. 

I run it from a file watcher using gulp to update my routes amtomatically as I edit. 

I'm happy to have feedback and collaborators - all input is welcome. Pretty close to ready for a 1.0 release.

You can find it here: https://github.com/richgoldmd/fat-free-routes and on packagist.org here: https://packagist.org/packages/richardgoldstein/fat-free-routes

[Nuwanda]

Well done. Good to see some fresh development in F3.

[ikkez]

hi,
yes the usage of annotations in php to define the routes is a nice idea.
I'm just wondering if it's also possible to run the routes parser at a certain point in the application directly instead of a gulp task. Since you're also having a route cache, it should be easy to call it based on an event (cache file missing, expired, or files have changed).
I'm thinking about taking this idea and move it to my cortex plugin, so I can define model fields by just adding properties to a model class and give them a certain annotation in the doc block for the used table column type or relation setup.. could be cool I guess ;)

[richgoldmd]

We could certainly run it from within the framework, and cache the results in whatever cache engine is setup instead of a file (for performance) - I'd be a little concerned about the performance hit of testing the controller files for revisions essentially on every hit.

I can definitely see a use in the cortex plugin - thats a good idea but you'd need to devise a way to proxy the setup calls out to the generated code - i.e. a hook o call INTO your cortex class form generated code to apply the effect of the annotations.

I am very comfortable with dev-time tooling and file watchers - and its very speedy so the regeneration when I save changes to a controller is negligible - I'm a little wary of run-time generation because it isn't performant, and in practice controllers, model files, etc don't change, except in development. But I wouldn't make run-time integration a condition of using annotations in cortex in any case. It would still be useful as a dev-time tool. I use it as a gulp task, but it could be executed by any task runner or ide file-watcher (i've used it as a file watcher in PHPStorm for example - in both cases I have it watch just the files of interest - eg. my controller directory)

I'm happy to collaborate on some ideas like that - resulting in a nice suite of annotations to augment F3 and ease development. In l=the latest revision I generalized the tag recognition in order to support PSR-5, but the whole tool can be architected to have specific tag type handlers, i.e. a plug in architecture to enable expansion.

Let me know your thoughts!

Rich

[richgoldmd]

Actually, to clarify, a tool that did what you are suggesting for cortex would need to generate code to save the indicated information in the hive under a known, predetermined key, and the cortex class constructor would query the hive (upon instantiation) for the key and apply the necessary changes to the instance.That data could be an assoc array, for example, in the generated code, with a key for each such annotated class and whatever structure is required to get the desired result. 

[richgoldmd]

Hi @ikkez, 

The code has been refactored now to have a pluggable architecture so adding new tag handlers is easier. I still have to work on the documentation, especially for the plug in interface, and it could use some more unit tests.

The tool can now aggregate generated code from multiple plug-ins into a single includable PHP (and optionally JS) file. Additional tags can use the same or new tag namespaces - each plugin can optionally define its own tag namespace.

On Wednesday, January 10, 2018 at 6:34:43 PM UTC-5, ikkez wrote:

[@eazuka]

@richgoldmd, @ikkez,

any update on this integration into cortex?