oldnotes

Provides admin skeleton for application

Components are built as module

Each module has
  Public routes
  Admin routes
  Custom settings routes
  File based config
  Database based settings

File structure

/
  src/ (PSR-4, PSR-0)
    config/
      settings.json
      *.php (normal laravel style config, there will be a symbolic link in the CMS to make this easier to get to)
  module.json

BlockView class extends Illuminate\View
  BlockView::make
    First looks for related view in the current theme directory
    If no view matches in the theme, then the Block's view is rendered

settings.json Schema
  Array of Soft Setting Objects
    title
    type (string, array, number, select [drop down options])
    options (only if select)
    min (only if number) - defaults to 0
    max (only if number) - defaults to null
    default

module.json Schema
  title
  description
  routes
    public
    admin
    settings
    (Route Object Schema)
      title (used for H2, etc)
      route name (used to match linkRoute)
      description
      icon - (optional)
      arguments/segments for route
        name
        description
        default

thoughts.md

I want to build a content management framework. Let me describe what I mean by that.

My vision is that you could develop a module that would drop in to the CMF and have public features, admin features, and really any other routes you want to work with manually. Database interaction would be on top of an ORM and would use migrations for clean database interaction and database tables that aren't dictated by the CMS.

I would like for a lot of the configuration to be handled using JSON files or something similar.

On the admin side of things, there would be an authentication and authorization module that would provide a unified interface so that you do not have to write user auth everytime. Since there would be an Auth interface, developers could easily swap out the Auth provider for something a bit more custom without hurting core functionality.

From there, the admin area will have a skeleton view for modules to plug in to. The base menu system will be generated based on the installed modules definition JSON files. These would route to flexible views where anything returned from the module admin controllers would be inserted into the larger admin layout. For easier building of admin forms, views, etc, there would be some modified view helpers which would help take care of boilerplate required to build forms with validation and more. But, at the same time, the module developer will be able to go as low level as they want within the admin viewport.

Modules also would have two methods of configuration options: hard and soft. Hard config options would use a file based configuration and be more developer centric. Soft configuration options would be a bit like a unified key-value store for end-user modifications within a module (for instance a contact form module might have a mailTo configuration option).

Publicly available routes would really need to be awesome. For this, I think there are two things it needs to have out of the gate.

1. A really smart view class - this would look for a view for the current route within the active theme, if it cannot find it, then it will use the module's default view
2. A smart and easy to use menu system - given that modules will define their publicly available routes, then the CMF should be able to have a view helper that will go and build menus based on the defined routes (and configuration).

To be viable, I think if not at launch the CMF has to have the following modules built by the core team:

1. Blog with comments
2. Pages (for static pages)
3. Contact form

There's a lot I would like after that which would help with module development:

1. Good scaffolding tools - similar to Jeff Way's generators, but opinionated towards building things for modules
2. A message bus between modules - I'd like to make it easy to make code with seperations of concerns. When working with CMS plugins in the past, I was absolutely angered by how coupled plugins were to each other and how they did not have a good API to interact with one another.
3. An awesome AJAX editor - this gets into a targeted package which I would like to see available, but it would be nice to have a package that made handling an AJAX based editor (like Sir Trevor) crazy easy. Like as easy as CMF::routeSirTrevor('url', 'ModelName') where ModelName could be a Eloquent model or a receiving repository.