Skip to content

Instantly share code, notes, and snippets.

@brendo

brendo/Symphony Scratchpad.md

Created September 11, 2015 15:14
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save brendo/52eaeed02e8e3646759b to your computer and use it in GitHub Desktop.
Save brendo/52eaeed02e8e3646759b to your computer and use it in GitHub Desktop.
Download ZIP
Musing about Symphony, rebuilt with modern concepts and tools
Raw
Symphony Scratchpad.md

Symphony

Baseline

  • PHP 5.6+ (also tested on HHVM, PHP 7)
  • Code style PSR-2
  • Autoloading to PSR-4
  • Logging will be abstracted to PSR-3
  • Requests / Responses should follow PSR-7
  • Must have test coverage (consider a combination of Behat/PHPSpec, or even just PHP Unit)
  • UI likely to remain similar/unchanged (little to no resources available)
  • No backwards compability with existing Symphony

Concepts

  • Extensions / Events / Datasources / Sections / Views remain (ableit updated to work in a more modular way)
  • Delegate system refined to align more with traditional Event Dispatcher
    • Both Extensions and Core will use common events instead of two different paths (which lead to more delegates than necessary and extensions that are more powerful than the core!)
  • Admin to dog food the core components (is an Extension)
  • Templating system becomes agnostic. Data should remain as PHP and transformed/serialized as required according to the choosen templating system (which will remain as XSLT by default... Twig/Blade support to be provided by third party?)
  • Configuration to stay as PHP (no interest in supporting YAML/XML like Symfony, but it shouldn't be coded in a such a way that this is impossible...)
  • Command line tool essential (Artisan is absolutely brilliant and sets a great benchmark)

Alleviate me

  • Views to be file based for better visibility within source control
  • Content/Section relationships to be totally rethought
    • Consider use cases commonly asked about (filtering based off 'x' field, limiting, uniqueness etc)
    • UI and logic to be decoupled for better extensibility
  • Poor internal API for consuming content (all CRUD operations are overly difficult)
  • Minimise field methods (too many methods for specific use cases), leverage more modular concepts like Export/Import interfaces
  • Remove limitation on Events first, then Datasources. The two concepts can be interwoven.

Anatomy

  • Symphony bootstrapped
    • Load Service Providers
    • Load Extensions (which may also have Service Providers)
      • Still like the idea of Extensions being 'installed' from a UI/Command and working. If possible, don't want people to have to edit a master 'Service Provider' listing.
      • Register middleware (?)
  • Request comes in
  • (Pre Routing) Middleware acts on the request
    • Symphony provides default middleware to check various things, however it should be extensible by extensions (orderable)
  • Route Request to appropriate Controller
    • Routes to be compiled from various sources and read thereafter (similar to Symfony2 cache) for speed. Routes should be definable in an easy way (extension) or from a component (admin will allow new routes to be created remember!)
  • (Post Routing) Middleware acts on routed request
    • To handle things like the route being flagged as 'admin' and therefore requiring 'x' guards to be run
  • Controller handles request
    • POST/PUT/PATCH/DELETE => Events
    • GET => Data sources
    • Both have access to parameter pool
  • Response is created
    • Agnostic data format, POPO
  • Response is serialised, transformed and returned
    • Probably based off a system => route => request chain, eg. XSLT set system wide, request wants JSON so POPO is json_encoded instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment