Download the PHP package grithin/control-path without Composer

On this page you can find all versions of the php package grithin/control-path. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package control-path

ControlPath

Load control files in path, using section controllers if they are found

Why

The router I previously built would load control files parallel to a requested url path. It included section control files that acted like frontware, and it provided an intuitive location for control files. But, it had some downsides:

I also considered that standard Controller class paradigm had downsides.

So, I resolved to have the best of both worlds and made this tool.

What

ControlPath loads page controls. The returns from the controls are collected, and they form the array that is returned from the load function.

How to interpret these returns is up to the application. For instance, the controls could return a response object, or a string which something else turns into a response object.

Let's look at an example.

With a path of /section1/page, the steps a flow goes through while($Flow->next() !== false) are:

  1. .
    • load /Controller.php
    • $Controller = new Controller()
    • $Controller->_always()
  2. .
    • load /section1/Controller.php
    • $Controller = new section1\Controller()
    • $Controller->_always()
  3. .
    • load page.php

Section Control

section1\Controller.php

Page Control

There are four variations that a page control can take:

Section Class Method

In Controller, within the section Controller.php, a method can correspond to the page name function page1(){}

Page Class

Parellels section controller class, but is named for the page. /page1 -> class page1{}

Closure

Can return a closure. The closure will have parameters injected.

Page Logic

The page itself can just do stuff. It can still return something - like the output of a template.

Injection

The methods, closures, and __constructs have normal dependency injection. Additionally, some parameters are injected based on the name of the parameter. The named injections are based on the inject option. Two variables are always injected:

You can have these injected just by name:

Sharing

It is intended that section controls and page control may want to share data. To enable this, the $share variable, which is an ArrayObject, is injected. This can also be used to capture methods within a Controller class.

Controller.php

page.php

Whereas, normally, a section Controller would have protected methods that it shares amongst the page methods within the class, if a section controller wanted to provide access to those methods to either page controls that weren't methods, or page controls that were deeper, it would have to do something like the above.

If necessary, the previous Controller classes can be access with $Flow->controllers. This allows accessing public data (object properties) on the Controller that might be useful. However, owing to the fact that public methods with the Controller are accessible via path, only pages (and builtins) should be public methods, and utility methods should be protected.

Stopping Control Flow

There are a few ways to stop control flow:

  1. return false from a control
  2. call $Flow->stop()
  3. throw exception

Where #2 occurs can be in multiple places. Since $Flow is injected:

Controller.php

Return handler

Conforming Path Tokens

Since path characters can diverge from what is allowable as a namespace or class, the token parts of the path are converted using ControlPath::token_to_class.

'.-' are used as separated, non-conforming characters are removed, and the token is turned into camel case:

029bob.bill-sue1 => bobBillSue1

Exceptions

Misc Design Notes

Class Files Vs Logic Files

Multiple load's become a problem when there is a mixture of class files and logic files. You can not re-include a class file, but a logic file expects to be re-included. As such, when ControlPath discoveres a class file, it will not try to load it again on subsequent runs.

ServiceLocator singleton ControlPath

There is a question of whether the ControlPath should clone the ServiceLocator or not. ControlPath adds itself to the SL. By having a cloned SL, it ensures if a control file calls SL->get(ControlPath), this will always points to the instance loading the control file. However, this creates a mismatch of expectation:

In the end, I decided not to clone ServiceLocater. ControlPath can be injected by name instead of by type, which means control files only need to name the param $ControlPath to ensure they are getting the current instance.

Why is Route Middleware Deficient?

Generally, there are complexities that apply to specific paths that would make the abstraction into front/middle ware both unnecessarily disconnected and would result in unnecessarily complex general middleware or route specific frone/middle ware. One off frontwares, indicated by path, fit perfectly for these path specific complexities, to be loaded as section controls. And example might be some series of complex permission checks which would not fit in a Auth middleware configuration parameter.

Controller Class Downsides

Why Not Controller As Api?

APIs + response handlers are good for handling standards. But, a controller can output anything, and sometimes a large variance from a standard is necessary.

Plans

Setting this up into a framework takes some effort.

Having something like laravel with route methods (Model $model) would mean injecting Model(Request $request), which would mean Request is a service or is otherwise injectable at that point.

Fitting ControlPath in with other wares, where there is the potential section controls will add more wares is also complicated:


All versions of control-path with dependencies

PHP Build Version
Package Version
Requires php Version >=5.3.0
grithin/file-include Version ^0.1.0
grithin/ioc-di Version ^0.5.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package grithin/control-path contains the following files

Loading the files please wait ....