Application:directory structure

From Surebert wiki

Contents

Overview

The surebert framework is divided into both a public and private section. The public directory is the application document root as is publically accessible. Any request that does match a file in the public directory is passed through the gateway to the private directory views.

Diagram

This flow chart is an overview of the framework

Flowchart of surebert application.

Public Directory

This is the publically accessible file structure. All files here can be publically served. If a requested file is not found in the public directory structure, than the request is routed to Gateway.php which routes the request to a controller in the /private directory.

.htaccess

See Framework:.htaccess for more info

  • instructs apache how to handle file expiration
  • directs unmatched requests to the gateway.php in order to load views
  • handles ntlm authentication, etc

gateway.php

  • This does the heavy lifting of accepting arguments from the request URI or command line and assigning the controller which calls the corresponding Controller - defaults to IndexController
  • Basically, all communication with the /private directory is done through this file.
  • You should not have to touch/customize this file, however, I encourage you to explore it

See Framework:Gateway for more info

/content

  • publically accessible user uploaded/generated content that requires no auth

/css

  • static site CSS files that are not served as views

/js

  • static site js files that are not served as views

/media

  • background images, buttons, logos, icons, etc
  • Not public content uploaded by users - use /content for that

favicon.ico

The favicon for the site. Replace with whatever favicon you want

Private Directory

This is the non-directly accessible backend of the application. The only files that are publically reachable are those views which you define in /private/view, otherwise none of the files can be reached via browser.

/cache

  • all temporary cached content, temp files, processing data, etc
  • Must be writable by apache/php

/config

definitions.php

  • This "global include file" is called before any requests are processed. It is useful to add two additional files definitions.prd.php and definitions.dev.php. These will load according properties for prod vs dev.

App.php

  • App.php loads with every page request.
  • The App class is a non-instantiated static class.
  • It is basically a storage for globally scoped properties and methods specific to your App.

/controllers

/development

  • Like all /private directories besides /view, this directory is not publically accessible so it is safe to store dev data here
  • all development notes, files, readmes etc meant for the programmer to read

/logs

  • Any machine generated log files
  • Must be writable by apache/php

/models

  • The model classes that represent objects in your application e.g. User, Admin, ShoppingCart, Patient, Building, Evaluation, Chicken, Car, etc
  • Each model class must be in a name-matching php file e.g. Evaluation.php contains class Evaluation
  • See Framework:models for more info

/resources

  • Any resources that are processed by your system before consumption. E.g. font-files, executables, large tiffs that are cut up, etc

/views

  • Represents the display output HTML, txt, csv, xml, json, etc
  • Each view is stored in a subdirectory but only one subdirectory e.g. /fruits/red.view would map to /fruits/red url
  • See Framework:views for more info

/mod

Additional mods that exist outside the project. The gateway will look for processing routes in here is they do no exist in the main project.

/example/

This would be the name of your mod, in this case mod_example, so the mod subdirectory is called example.

/controllers

Any controllers that are part of the mod, same structure and usage as views in the main project. The gateway has preference for controllers in the main application, meaning you can add new controllers to the application but not override any existing controllers.

views

Any views that are part of the mod, same structure and usage as views in the main project. The gateway has preference for views in the main application, meaning you can add new views to the application but not override any existing views.

init.php

Runs everytime Gateway::require_mod('YOUR_MODULE_NAME'); is run

install.php

Can be used to install things from the module into the main project. Must be run manually from command line.

uninstall.php

Can be used to uninstall things from the module into the main project. Must be run manually from command line.