Skip to content

Structure

Introduction

├── app (directory)
| ├── Actions (directory)
| ├── DataTransferObjects (directory)
| ├── Drivers (directory)
| ├── Events (directory)
| ├── Exceptions (directory)
| ├── Jobs (directory)
| ├── Listeners (directory)
| ├── Observers (directory)
| ├── Presenters (directory)
| ├── Providers (directory)
| ├── Statuses (directory)
| ├── Subscribers (directory)
| ├── Traits (directory)
| └── Types (directory)
├── bootstrap (directory)
├── config (directory)
├── database (directory)
├── modules (directory)
├── plugins (directory)
├── storage (directory)
├── Support (directory)
├── tests (directory)
├── themes (directory)
└── workers (directory)

App directory

The app directory contains application specific code. The contents of this directory are explored in more detail after this section. In summary, this area contains business logic that doesn't belong in traditional plugins. Most of the plugin features are available in this directory.

Actions directory

Contains normal classes that have only one main method handle which execute only one task, this concept been used to apply Single Responsibility Principle in SOLID. For example: the action SendStudentApplications handles the process sending student to the Integration Broker which will be explained in S-Apply Integration part. Also it contains Application actions for the each application cycle. e.g:

namespace App\Actions;
 
class DummyAction [extends BaseAction]
{
public function __construct(public $data)
{
//...
}
 
public function handle()
{
//...
}
}

Usage:

use App\Actions\DummyAction;
 
//...
 
function foo()
{
//...
(new DummyAction(['foo' => 'bar']))->handle();
//...
}

DataTransferObjects directory

Short-wrote as DTO is a plain class with only static methods starts with from word, e.g: fromFoo. used to pass data from one layer to another independent from any business logic, useful for abstraction and insure data consistency. e.g:

namespace App\DataTransferObjects;
 
class DummyData extends DataTransferObject
{
public static function fromArray(array $data)
{
return new self($data);
}
}

Usage:

use App\DataTransferObjects\DummyData;
 
function foo()
{
//...
$data = DummyData::fromArray(['foo' => 'bar']);
//...
}

Drivers directory

Contains only one class currently used to fetch programs from s-apply site to map into system for S-Apply Integration. Can be refactored to an action, See actions

Events directory

Contains events classes, just normal php classes with common two traits:

use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\SerializesModels;

used to trigger an event then Listeners can handle it.

Exceptions directory

For defining custom exceptions and globally catch exceptions and define general behaviour. useful in common http codes exceptions.

Jobs directory

Defining queue scheduled jobs, usually a class with a single task that is slow enough to not let the user suspended until it completed.

Listeners directory

A class that listen to trigger events that are linked in app/Providers/EventServiceProvider.php class, added to the $listen array. The relation is One(event) to Many (Listeners). also can be registered in the boot method on any ServiceProvider class using global class(Facde) called Event like this:

use Event;
//...
//...
//...
public function boot()
{
//...
Event::listen(SomeEvent::class, [
FirstListener::class,
SecondListener::class,
//...
]);
}

Observers directory

Observers are special type of Subscribers/Listeners that only listen to Laravel Models events, e.g(created, updated, deleted, ....). registered in app/Providers/ObserversProvider.php class on boot method using the method observe like this:

//...
public function boot()
{
//...
SomeModel::observe(DummyObserver::class);
}

while DummyObserver class contains public methods that match the name of dispatched model's event.

Presenters directory

Represents the P letter from MVP pattern (Model-View-Presenter). basically the presenter is a class that modify the data coming from DB(Model) before it sent to the view to seperate the logic of presenting a information. to use this in OTAS you need to make your model use the trait HasPreseneters then define the presenters you want to use in the $presenters as $key => $value (presenter_alias => DummyPresenter::class) then you can use it on any view by using the method present, in Twig for example:

{{model.present('presenter_alias')|raw}}

Providers directory

It a Laravel implementation of IoC Container, you can read more in Laravel official docs.

Statuses directory

A special classes that extends ApplicationStatus used to represent each status in the student application lifecycle to seperate logic and make the application status interchangeable from any part of code.

Subscribers directory

Subscribers are normal php classes that can used to listen to multiple events using methods instead of a listener class for every one task. normally used for related logic for one domain. to register a subscriber class first create normal class with a method called subscribe, then in app/Providers/EventServiceProvider.php class, add it to $subscribe array. after that start to add any methods and then map them to their corresponding event:

public function someEventHandler()
{
//...
}
//...
public function subscribe()
{
return [
SomeEvent::class => 'someEventHandler',
//...
];
}

Traits directory

Simply a directory to define common Traits or Concerns of your app.

Types directory

Here you can define you Value Objects data which can be used to encapsulate a compound value of a certain type. for example Money type has two common values: amount & currency. then you can add methods to add or substract or convert from currency to another and make it your own application type.

Config directory

The config directory contains all the application configuration files. Each file controls how the application functions. Configuration files can be changed according to your application requirements. System updates do not modify the configuration files.

Plugins directory

The plugins directory packages that extend the core functionality of October CMS. Plugins can modify the platform by introducing new features. By default, the system loads all plugins found in the filesystem. Specific plugins can be disabled using the system.disable_plugins configuration parameter.

Storage Directory

The storage directory contains log files, cache files, sessions and other files generated by October CMS. It includes several subdirectories:

  • app: contains application-specific storage files, such as media files, file uploads and automatically generated resources, e.g. resized files and combined asset files.
  • framework: used by the Laravel framework to store its generated files and caches.
  • cms: used by the October CMS platform to store its generated files and caches.
  • logs: contains the application's log files.
  • temp: used to store temporary application files.

Support directory

It was a directory to store classes and custom types of the app, but now after the October CMS upgraded to version 3, there is an app directory used for that. so for Refactoring part it is better to move the classes to app directory then delete this folder.

Themes directory

The themes directory contains subdirectories for front-end website CMS themes. CMS themes include template files for the website pages, layouts, partials, assets, and other files. The active theme is set using the cms.active_theme configuration parameter and can be overridden from the backend panel settings page.

Below, you can see an example theme directory structure. Each theme represents a separate directory, and generally, one theme is active to display the website. This example demonstrates the website theme directory.

├── themes
| └── spotlayer <em> Theme Starts Here</em>
| ├── pages
| └── index.htm
| ├── layouts
| └── default.htm
| ├── partials
| └── sidebar.htm
| ├── content
| └── footer-contacts.md
| └── assets
| ├── css
| | └── my-styles.css
| ├── js
| └── images</p>