Structure
- Introduction
- App directory
- Config directory
- Plugins directory
- Storage Directory
- Support directory
- Themes directory
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>