Skip to content

TODOs

Jump to bottom
Bill Lee edited this page Dec 3, 2017 · 4 revisions

Things to Do (that I've bothered to write down)

Tasks

  • Integrate consistency with PSR specifications. Consistent with the philosophy of not reinventing everything for the framework, would be the goal of adopting (most) of the PSR. The bolded items will be pursued earlier.
    • 1 Basic Coding Standard
      • Files MUST use only <?php and <?= tags.
      • Files MUST use only UTF-8 without BOM for PHP code.
      • Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
      • Namespaces and classes MUST follow an “autoloading” PSR: [PSR-0, PSR-4].
      • Class names MUST be declared in StudlyCaps.
      • Class constants MUST be declared in all upper case with underscore separators.
      • Method names MUST be declared in camelCase.
    • 2 Coding Style Guide
      • Code MUST use 4 spaces for indenting, not tabs.
      • There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
      • There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of use declarations.
      • Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
      • Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.
      • Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility; static MUST be declared after the visibility.
      • Control structure keywords MUST have one space after them; method and function calls MUST NOT.
      • Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
      • Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.
    • 3 Logger Interface
      • Augment and integrate ccTrace functionality Logger Interface
    • 4 Autoloading Standard
      • Consider using Common ClassLoader
    • 6 Caching Interface
    • 7 HTTP Message Interface
    • 11 Container Interface
    • 13 Hypermedia Links
    • 16 Simple Cache
    • Drafts
    • 5 PHPDoc Standard
    • 8 Huggable Interface
    • 9 Security Advisories
    • 10 Security Reporting Process
    • 12 Extended Coding Style Guide
    • 14 Event Manager
    • 15 HTTP Middlewares
    • 17 HTTP Factories
  • Update this, todo, content.
  • Clean up requirements/complexity of app.php config file, moving more defaults to ccApp.com.
  • Get PhpDoc working again and keep documentation up to date. (See ccPhp documentation).
  • Sort out dev vs prod settings (implies trace and error output)
  • Debugging/tracing component (work in progress: ccTrace, sort out usage).
  • Add example of DB/model component (Doctrine? RedBean?)

Fixes

  • Fix ccHtmlPage 404 result code (currently does not generate a 404 result code)
  • ccRequest: Do not eat URI "file extension"

Additions (non-breaking changes, hopefully)

  • Support Composer
  • ccController or ccSimpleController: Add tracing info to see what URL and methods are being attempted

  • ccApp

    • cache control header support
    • Support internal "redirection" support
    • Need for session support?
    • ob_start() support
    • Single ccApp::setDebug() to set "debug" setting that will cascade thru components.
    • Use Doctrine's Common ClassLoader rather than custom code ?
    • Optional app-dir parameter in createApp()
    • Override autoload/error/exception handlers should not be set until ccApp is active (probably within ccApp::createApp() or its constructor.
    • Add on init-log-file(), to output info only when created.
    • Add setLogFile(), setAppDir(js)
    • Clarify Root path vs Root URI (see ccRequest's RootURI)

  • ccRequest

    • Use constructor's URI rather than globals
    • Enable the isAjax() method to be easily overridden or augmented.
    • Add Cookie-functions, here or ccApp? (consider secure-only cookies)
    • Add getRequestValues() (use $_GET+$_POST or $_POST only, for secure, when non-debug)

  • ccController

    • Add optional parameter to describe how to getMethodFromRequest() to adorn the method name that corresponds to the path component.
    • Rethink its role and getMethodFromRequest(). Instead it should have its own render() implementation and an overridable getMethodName() and/or dispatch(). This might mean combining w/ccPageInterface or ccSimpleController
    • Routing support ?

  • ccChainDispatcher

    • Eliminate filter handling--not sure that it is needed.

  • ccHttpController: Base-class (abstract?) makes HTTP-methods more prominent

  • ccRestController: Simplifies REST oriented request implementations

  • ccAjaxController: Handle Ajax requests more naturally (JSONP support?)

  • ccReactController: supports ReactJS (and ReactJS-native?)

  • ccSassController: SASS support

  • ccSiteController/Dispatcher

Design Changes (breaking changes, probably)

  • Define an organization for components that are added (e.g., Smarty, LessCSS, etc.)
  • Consider adding a unified configuration mechanism to enable simple setting (and addition) of application specific values. This may not be necessary since such settings are easily added to the app.php file, programmatically (and that is consistent with its approach, anyway).
  • ccApp
    • Reconsider DevMode handling
    • Rename ccApp::DevMode() --> AppMode ?
    • Move error handling to ccError class (referenced by ccApp and tied to ccTrace(?))
    • Consider a separate "site" object (to allow site specific configuration), currently part of the "app" object.
  • ccController
  • ccHtmlPage rewrite (see notes in current ccHtmlPage)
    • Reimplement use of begin()/after() to free those up for normal derived-class overriding (call onPreface()/onEpilog() separately, explicitly)
    • Define packages, e.g., jQuery, Bootstrap, etc. which will perform the appropriate setup for the corresponding package (include CSS, JS)
    • Add meta tag support
    • Consider abstracting this by eliminating making body an explicit part of the interface, describing only: preface, content, and epilog. Then allowing augmentation of those three elements by inserting to top and bottom of each.
      • <head>
      • preface, epilog
      • style and script settings
      • Header
      • Footer
    • Font support?
  • ccSiteDispatcher: knows about site stuff. Settings can be overridden by ccHtmlPage
    • favicon.ico
    • title
    • Common
    • Common style and script settings
    • Common "preface", "epilog"
  • Apply namespaces to ccPhp components
    • Redefine/simplify namespace usage to group all intended "public" classes to be under the same namespace. A separate namespace is for those who are augmenting the framework. And another namespace for "private" implementation.
    • The namespace and "extras" may require a redefinition of how autoload() should work.
    • Need to classify namespaces (e.g., \ccPhp, \ccPhp\Page|Controller, \ccPhp\Internal, \ccPhp\Extra, ...)

Use Case

The original approach assumed the creation of a public stub (e.g., index.php) file directs to an application-specific bootstrap file (e.g., app.php) which links to the framework via ccApp.php. From there, create a ccPageInterface class generates content. To start, that can be contained in one class, extending one of the provided base classes. This is three groups of code, the public code, the app-specific code, and the framework.

  • We can simplify this for some scenarios by allowing the content generation class to be the sole application implementation class. It would link to ccApp.php, but a lot of the content of app.php could have default settings which would be implemented in the ccApp.php framework initialization. This would reduce the minimal groups to two, the public code and the framework, for simple applications.
  • Since the approach is programmatic, it would be nice to have a structure that directly paralleled HTML structure. I've started this with the ccHtmlPage class (which might be renamed to ccHtmlController)

Old Notes

  • Allow site paths to auto-generate paths.

  • Create structure of simple front-end event mapping to support here.

  • CSS and JS compression/minimization support for production mode.

  • Logging support.

  • MODE_PRODUCTION should prevent revealing errors (hide path info)

  • ccApp

    • Consider moving most of app.php code to index.php? No. Keep most of this out of public/hacking view

  • ccChainDispatcher

    • Move error handling ccError class and refer through ccApp

  • From ccHtmlPage: Implement these as if you were being called, live. The content of each is captured then output by the base-class so it can be performed in the correct order (e.g., onHeaders output is sent first).

    • protected function onPage() - Output page (this calls the subsequent)
    • protected function onHeaders() - HTTP Header output
    • protected function onHead() - Things within the head tag
    • protected function onBody() - Things within the body tags
    • protected function onContent() - Core content, called by onBody()
    • protected function onScript($head=FALSE) - Things within the script tags top or bottom
    • // protected function after() - Common stuff to do before each action (ccSimpleController)
    • // protected function before() - Common stuff to do before each action (ccSimpleController)
Clone this wiki locally