Liaison Development Status

Code Work

Next

• (current) Error Component
  • Working on error_goto.
    • Need an Error Route (maybe as a public file, idk. Might make it configurable)
    • Need to setup test. I started the test, but can't really wrap my head around how to do it.
• Improve error views (header & page)
• Middleware & Routing
  • Add a 'handleRequest()' method that allows any component to handle a request
  • How does the web-developer decide who's handling requests? The middleware approach might be best. addMiddleWare() & removeMiddleWare() could be used by the Server component... It might use a couple if statements to determine which middlewares to add. But the flow would be the same regardless.
• Caching:
  • Routes from public files (Router)
  • Classmap of a package (autoloader)
• Cleaner Route interface/object
• Cleaner View interface/object

Latest

• Router component can have additional routers added to it for custom routing.
• Add append method to Config component
• Renamed package setup functions to setup_the_thing & added setup() function to move setup out of the constructor.
• Add namespaces to the view component
• Modify package to use namespace when calling view component
• Remove 'lia.packages'. This was a mistype & should have been 'lia.package' all along
• Convert package list to use namespace instead of name
• Separate SEO methods/api from Resource compo
• namespaced apis. converted api('lia.action', 'handler',...$args) to api('lia:action.handler', ...$args)
• namespaced configs with consistent naming like lia:componame.configName.
• Ensure there is a default() call for every config

Documentation work

Next

• Review property docblocks in Liaison class. They don't match with the api namespaces refactor.
• Continue Docblocking as marked below (in class/Objects/)
• Don't forget the Objects/ViewCallable.php: Need to review this when I'm doing the view component
• Write Markdown documentation AFTER docblocking is done
  • Write examples as tests & import

Latest

• Docblocked everything except compos
• Updated docblocks on Liaison methods to match api namespace refactor

Things that need to be in markdown documentation

• Specify your package's namespace in config.json. This is separate from name.
• List of available configs
• Full api reference for code/class and code/core
• Featured API Reference? For only listing featured methods & classes
• TODO reference file (grouped by file name in a single markdown file)
• All events & the paramaters they pass

Docblocking status

• Liaison.php
  • Mostly good
  • api methods (addApi, addApiMethod, etc...) are not well documented. Since I want to remove $handler, I'll probably wait on that.
  • Some things are a little under-documented, but the method-signature and the short function bodies... makes it not that big a deal
  • Not @tagged very well
• Compo.php
  • Well documented
  • @featured & @tag pretty well
• Package.php
  • Pretty well documented
  • Not sure about my @tags. There are @tag setup & @featured. I think there could be more organization there.
• CompoTrait/
  • Scanner.php
    • Docs pretty good.
    • trait needs some rewrite (thus docs will, too)
    • Only the class has @tag internals, component... Idk.
• Exception/
  • Base.php
    • Wrote @todos.
    • Nothing really needs documented here. You just create an exception
  • *.php
    • I plan to delete the other exceptions & improve BaseException with extensibility. So... No. Not documenting these
• LiaisonInterface/
  • LifeCycler.php
    • @deprecated & @todo delete, because its not in use far as I could grep
  • PackageLifeCycle.php
    • Documented nicely. But documentation is nearly identical to documentaiton on \Lia\Compo for these methods. Perhaps I can remove identical docs from compo.
• Objects/
  • IView.php
    • Documented, some @todos
  • View.php
    • Well Documented, some @todos
  • Request.php
    • Well Documented, very basic class
  • Response.php
    • Reasonably well documented. Some @todos
  • Route.php
    • Adequately documented... bad class.
    • No tags... I might want tags
  • ViewCallable.php
    • TODO <- There is no structure. It's all setup by the View component, I think. So its not well setup for documenting
• Utility/
  • ClassFinder.php
    • Barely documented, because it comes from my Utility repo. So its fine.
  • DotNotation.php
    • documented well enough. No tags
  • FancyClosure.php
    • documented well enough. No tags
  • Files.php
    • Documented well enough. No tags
  • StaticFile.php
    • Documented well enough. No tags
• ../core/
  • Has not been started

Future Work

View Getters

The base View Component will implement a view() method. This view() method will loop over all active view_getters & call getView() on each of them. The returned view will be an instantiated class with a __toString() method. Exactly one view getter must return a view. Each view getter MUST support namespaced view names.

• Phad templates & Lia views will both be accessible through $lia->view().
• Lia\Compo\View will
  • implement a view getter
  • have an add_view_dir($dir, $namespace, $args) function that adds a dir for PSR-4 style view-name loading
  • have an add_view_callable($callable, $fullyQualifiedViewName, $args) function to explicitly add a callable as a view
  • have an add_view($dir, $fullyQualifiedViewName, $args) fucntion to explicitly add a single view
    • this is already implemented
• Phad\Compo will
  • implement a view getter
  • have an add_view_dir($dir, $namespace, $args) function for psr-4 style view loading
• Some Future View Component will
  • implement a view getter
  • have an add_whatever function to add whatever.... to be later retrieved by the view getter method