Liaison

A PHP Framework and a set of components for developing webapps and websites

Structure

• Liaison manages apis & their global aliases.
• Lia\Package handles resources in a given directory:
  • load configs & manage them
  • load components & manage them
  • load views
  • convert public files into routes
  • set up autoloader
  • has LifeCycle functions, which are handled by a built-in component
• Lia\Compo is a base class to simplify setting up components
• dir class/Object/* are objects used by built-in components
• dir class/Utility/* are Utility classes
• dir view/theme provides a default theme
• dir file/mime_type_map.php is just that

Components

Components create all the features. Lia\Package calls upon several of these components

• Autoloader: loads classes within given directories
• Cache: caches files with given content for specified time period
• Config: Handles global configurations (used across packages) and can propagate configs to packages
• Error: Handles both internal errors & request errors. @TODO
• Event: api to schedule and emit events,
• GlobalParam: Manages variables that should be given to all parts of a Liaison server.
• LifeCycle: Manages objects that have lifecycle methods. Executes onPreMethod and onMethod when the registered lifecycle starts
• PackageList: Keeps a list of packages, accessible by name
• Redirect: Redirect requests, with content, if desired.
• Resources:
  • Add css & js files, urls, and/or code blocks to a request
  • Sorting api to set order of resource files in compiled output
  • Routes to compiled resource files
  • Manages seo information (this should go in a new component)
  • Outputs headHtml (must be called)
  • Passes compiled files to cache component
• ResourceSorter: A wrapper around the Resources sorting api, to make it easier
• Router: Set pattern & static routes. Parse paramaters from urls. Process url for route target (package, callable, file)
• Server: Handles request delivery
  • Helps all the components work together to respond to a url
  • delivers static non-php files
• View: Register views, and create View objects from given paramaters.

Directory Structure

Directory structure is COMPLETELY determined by the Package class you're using, not by Liaison. This structure is defined by our built in Package class.

aPackageDir/  
    - config.json <- Package settings  
    - public/ <- Public files to be routed to. Ex: `public/contact.php` routes to `/contact/`  
    - view/ <- Views  
    - core/ <- Components (generally extending from \Lia\Compo)  
    - class/ <- Classes to autoload, PSR4 style. Will be converted to classmap style later  
    - cache/ <- Where to store cache files. Though cache files are stored in a global package dir, not a package-by-package basis  

Some Awful Things

• Environment-driven features are not built-in, but I recommend my Env php class
• There is no namespacing. But there WILL be namespacing. (of views, apis, public files)
• I use funky function naming conventions instead of attributes.
  • At its best: onEmitEventName(...$args); <- To handle an event being emitted
  • At its worst: apiPrefix_lia_autoload_autoload_addAutoloaderFromPrefix($key, $callback) <- to add any public function autoloadWhatever($className) to spl_autoload_register
  • The alternative: myFuncName($whatever); then call $lia->addApi(), $lia->addApiMethod() and $lia->addApiPrefix()
• A file cache exists, but not a key=>value cache, and its horrible
• The Server class is incomplete, so... the request lifecycle is garbage
• Package & component lifecycles are a mess

Request Lifecycle

1. .htaccess routes to deliver.php or wherever you like
2. Server setup: Database configuration, other non-liaison things
3. Create a $lia = new Liaison()
4. Create new \Lia\Package($lia, $packageDirectory) for each package you're using
5. $lia->deliver($url) <- leave out $url to use default of $_SERVER['REQUEST_URI']
6. Each Package->onStart() is called, registering views, routes, and components with $lia
7. A route is determined (by the Router component)
8. ob_start(), execute route, $content = ob_get_clean()
9. emit Server.willDisplayContent($content)
10. The theme is loaded & passed $content OR headers are set for a raw file (if the route leads to a static file like an image or css)
11. The result of #10 is echo'd, the connection is closed (only supported by some servers), then Server.responseSent() event is emitted

Some things that really need to be done

• Set no-cache headers for non raw-file requests
• Write docs for declaring APIs
  • Review the Api trait & see if I can make it more intuitive
• Add namespacing of views, public files, & other package-specific components
• Document all prefixes available & how to use them & how to change them
• Stop relying upon the funky function naming conventions (but don't get rid of prefixing alltogether)
• simple key=>value caching
• Document both PACKAGE lifecycle AND component lifecycle
• Basically just document how to use everything