Властивості фреймворку

Фреймворк буде містити наступні властивості:

– CatchAll – властивість, яка буде вказувати на дію контролера та мусить обробляти всі вхідні запити від користувача. Переважно, це буде використовуватись, коли система знаходитиметься в режимі обслуговування і повинна обробити всі запити через одну дію. Конфігурація буде масивом, перший елемент якого вказує на маршрут дії. Решта елементів масиву будуть у форматі ключ-значення та будуть вказувати на додаткові параметри, які мають бути передані дії;

– Components – властивість, яка дозволить зареєструвати список іменованих компонентів системи, які можна буде використовувати в інших місцях. Кожен компонент системи буде визначений у форматі ключ-значення в масиві. Ключ буде представляти собою ідентифікатор компонента, у той час як значення буде представляти собою назву класу або конфігурацію;

– ControllerMap – властивість, яка дозволить встановлювати відповідність між ідентифікатором контролера та його класом. За замовчуванням система буде встановлювати відповідність між ідентифікатором контролера та його класом згідно правилу включення (наприклад, ідентифікатор post буде відповідати класу app\controllers\PostController). За допомогою налаштування даної властивості можна буде обійти правило для необхідних контролерів.

– ControllerNamespace – властивість, яка буде вказувати на простір імен за замовчуванням, в якому повинні знаходитись класи контролерів. За замовчуванням значення буде рівне app\controllers. Якщо ідентифікатор контролера є post, то, за правилом включення, відповідна назва класу контролера (без простору імен) буде PostController, а повна назва класу буде app\controllers\PostController. Класи контролерів можуть також знаходитись у під-каталогу каталога, відповідно до їх простору імен. Наприклад, ідентифікатору контролера admin/post відповідає повне ім’я класу контролера app\controllers\admin\PostController. Потрібно щоб повне ім’я класу контролера могло бути використане автозавантаженням і фактичний простір імен контролера відповідав цій властивості. В іншому випадку, користувач отримає помилку із заголовком "Сторінка не знайдена" ("Page Not Found"). У випадку, якщо потрібно обійти правило включення, то можна використовувати властивість controllerMap;

– Modules – властивість, яка визначатиме модулі, які буде містити система. Значеннями властивості буде масив імен класів модулів або конфігурацій, а ключами цього масиву будуть виступати ідентифікатори модулів;

– Params – властивість, яка визначатиме масив глобально доступних параметрів системи. Замість того, щоб використовувати жорстко фіксовані числа і текстові рядки у коді, краще оголосити їх параметрами системи в одному місці і використовувати в необхідних місцях коду. Наприклад, можемо визначити розмір мініатюр зображень як параметр та надати їй змінну (наприклад, thumbnail.size' => [128, 128]). Якщо пізніше потрібно буде змінити розмір мініатюр зображень, то потрібно буде змінити це значення лише у конфігураційному файлі системи, не змінюючи будь-який залежний код;

– Charset – властивість, яка вказуватиме кодування, яке використовує система. За замовчуванням значення рівне 'UTF-8';

– ViewPath – властивість, яка визначатиме базовий каталог, де містяться всі файли представлень.

Компоненти фреймворку

Фреймворк буде містити наступні компоненти:

– Db – буде відповідати за з’єднання з базою даних, через яке можна виконувати запити до бази даних;

– ErrorHandler – буде здійснювати обробку помилок і виключень PHP;

– Formatter – буде здійснювати форматування даних для відображення їх кінцевому користувачу (наприклад, число може бути відображене із роздільниками тисячних розрядів);

– Mailer – буде надавати можливості для побудови і відправлення поштових повідомлень;

– Response – буде представляти собою об’єкт відповіді сервера кінцевим користувачам;

– Request – буде представляти собою об’єкт запиту, який сервер отримуватиме від кінцевих користувачів;

– Session – буде надавати інформацію про сесію;

– Urlmanager – використовуватиметься для розбору і побудови URL;

– View – використовуватиметься для формування представлень.

Проектування маршрутизації

Кінцеві користувачі будуть звертатись до дій з допомогою так званих маршрутів. Маршрут – це текстовий рядок, який складатиметься з наступних частин:

– ідентифікатор контролера – текстовий рядок, який унікально ідентифікує контролер серед всіх інших контролерів;

– ідентифікатор дії – текстовий рядок, який унікально ідентифікує дію серед всіх інших дій одного й того ж контролера.

Приклад маршруту: ControllerID/ActionID. Таким чином, якщо користувач звертається до URL http://hostname/index.php?r=site/index, то буде викликано дію index у контролері site.

Безпека даних

Дані для моделі, які отримуються від кінцевих користувачів, повинні пройти перевірку, щоб пересвідчитись, що вони задовольняють певні правила (перевірка на правильність даних, наприклад: логін, пароль, email). Якщо значення для деяких атрибутів не задовольняють відповідні правила, то будуть відображенні належні повідомлення про помилки, щоб допомогти користувачу виправити їх.

Форму моделі даних, яку повинен заповнити користувач вже створеної системи за допомогою розроблюваного фреймворку потрібно перевіряти для цілісності та безпеки всієї системи. Тому фреймворк повинен мати метод валідації validate(). Даний метод повинен повертати значення true та false. Метод валідації може використовувати правила перевірки, які розробник може вказати в методі rules() класу Model. Код правилу може бути вказаним наступним чином: return ['password' => [['password'], 'string', 'max' => 60]]. В даному прикладі визначаються перевірки, тобто отримане поле password з форми, яку заповнив користувач системи, повинно бути перевірено за правилами обробки паролів (перевірка на ін’єкції та тому подібне), також вказується тип даних «string» та максимальна кількість символів 60.

Валідатори повинні надавати можливість розробнику створювати повідомлення про помилку користувачу. Наприклад, required валідатор додає до моделі повідомлення про помилку "Ім'я користувача не може бути порожнім." коли атрибут username не задовольнив правилом цього валідатора. Також, можуть бути поля, які не обов’язково заповнювати користувачу, такі дані не будуть проходити валідацію, тому що їхнім результатом буде порожній рядок і для них буде встановлено значення NULL. Код перевірки на пустий рядок може виглядати наступним чином: [['username', 'email'], 'default']. Де «default» означає, що дані, вказані в масиві, можуть мати значення NULL.

Багато розробників знають, що зберігати пароль відкритим текстом не можна, але багато хто до цих пір вважають безпечним використання для хешування паролів md5 або sha1. Раніше згаданих алгоритмів було досить, але сучасне обладнання дозволяє підібрати ці хеші дуже швидко, методом простого перебору. Для того, щоб забезпечити підвищену безпеку паролів користувачів в системі, потрібно використовувати алгоритм шифрування, стійкий до атаки перебором. Кращий варіант в поточний момент – це шифрування методом bcrypt. Коли користувач задає пароль (наприклад під час реєстрації), то він повинен бути зашифрований (захешований). Хеш можна буде пов'язати з відповідним атрибутом моделі, так щоб він зберігався в базі для подальшого використання. Коли користувач спробує увійти, відправлений в формі авторизації пароль повинен бути захешований  і порівняний з раніше збереженим хешем. В результаті, користувач або отримає доступ до системи (значення true), або користувач отримає повідомлення про помилку (false).

Представлення

Представлення є частиною архітектури MVC. Це код, який відповідає

 за відображення даних кінцевим користувачам. У WEB системі представлення зазвичай створені у вигляді шаблонів представлень, які є файлами скриптів PHP, що містять переважно HTML-код та презентаційний PHP-код. Управління ними здійснюється за допомогою компонента системи view, який надає часто використовувані методи для полегшення компонування та формування представлення. Для простоти, часто шаблони представлень або файли шаблонів представлень називаються представленнями.

Представлення, які формуються контролером, повинні бути розміщені в директорії app/views/ControllerID за замовчуванням, де ControllerID відповідає ідентифікатору контролера. Наприклад, для класу контролера PostController директорія повинна бути app/views/post, для класу PostCommentController директорія повинна бути app/views/post-comment. У випадку, коли контролер належить модулю, директорія повинна бути views/ControllerID у директорії модуля.

Макети – особливий тип представлень, які представлятимуть спільні частини для інших представлень. Наприклад, сторінки більшості WEB систем мають однакові шапку та футер. Розробник зможе повторювати однакові шапку та футер сторінки у кожному представленні, також зможе зробити це один раз у макеті та розмістити результат формування вкладеного представлення у відповідному місці макету.

Оскільки макети є представленнями, вони можуть бути створенні тим самим шляхом, як і звичайні представлення. В фреймворку, який розробляється, макети будуть зберігатись в директорії app/views/layouts.

В макетах повинні використовуватись наступні методи:

– beginPage() – метод, який повинен викликатись на самому початку макету, який буде ознакою початку сторінки;

– endPage() – метод, який повинен викликатись в кінці макету, який слугує ознакою кінця сторінки;

– head() – метод, який буде викликатись всередині секції <head>

HTML-сторінки, він генерує заповнювач, який буде замінено зареєстрованим HTML-кодом (наприклад, теги link і meta), коли сторінка буде повністю сформована;

– beginBody() – метод, який буде викликатись на початку секції <body>. Він генерує заповнювач, який буде замінено зареєстрованим HTML-кодом (наприклад, JavaScript) на початку секції <body>;

– endBody() – метод, який буде викликатись у кінці секції <body>. Він генерує заповнювач, який буде замінено зареєстрованим HTML-кодом (наприклад, JavaScript) у кінці секції <body>.

Всередині макету розробник буде мати доступ до двох попередньо визначених змінних: $this та $content. Перша посилатиметься на компонент представлення, як і у звичайних представленнях, в той час як друга буде містити результат формування вкладеного представлення, який формуватиметься викликом методу render (обробник представлення) у контролерах.

Блоки дозволятимуть визначати вміст представлення в одному місці, а відображати в іншому. Вони можуть бути використані разом з макетами. Наприклад, розробник зможе визначити блок у вкладеному представленні та відобразити його у макеті.

Виклики методів beginBlock() та endBlock() визначатимуть початок та кінець блоку. Потім блок може бути доступним через $view->blocks[$blockID], де $blockID означатиме унікальний ідентифікатор, який розробник призначає блоку під час його визначення.

Кожна WEB сторінка повинна мати заголовок. Звичайно тег заголовку виводитиметься в макеті. Також заголовок може визначається у вкладених представленнях, а не в макетах. Для вирішення цієї проблеми, компонент View надаватиме властивість title, за допомогою якої можна буде передавати з вкладеного представлення до макетів інформацію заголовку. Для використання цієї можливості, в кожному вкладеному представленні можна буде задати заголовок, наприклад: $this->title = заголовок сторінки'. Для того, щоб заголовок правильно виводився, потрібно щоб в макеті в секції «head» було вказано наступний код: <title><?= Html::encode($this->title)?></title>.

До статичних сторінок відносяться ті WEB сторінки, в яких основний вміст здебільшого статичний та не потребує доступу до динамічних даних, що передаються з контролерів. Розробнику можна буде виводити статичні сторінки, розмістивши їх код у представленні, а потім використовуючи код подібний до наведеного у контролері, наприклад: return $this->render('about'), Де «about» – статична сторінка.

Кращою практикою для використання представлень буде:

– представлення повинні здебільшого містити презентаційний код, такий як HTML та простий PHP-код для подання, форматування та формування даних;

– представлення не повинні містити код, який виконує запити до БД (такий код виконується в моделях);

– представлення повинні уникати безпосереднього доступу до даних запиту, таких як $_GET, $_POST (за їх роботу відповідають контролери). У випадку необхідності дані запиту повинні бути передані в представлення через контролери.

Щоб в представленнях не було занадто багато коду розробнику краще використовувати макети для відображення спільних презентаційних секцій (наприклад, шапка та футер сторінки).

Встановлення власної теми – це спосіб замінити один набір представлень іншим без переписування коду, що чудово підходить для зміни зовнішнього вигляду системи. Фреймворк повинен надавати можливість розробнику встановлення власної теми. Для того, щоб існувала така можливість, потрібно щоб представлення мали властивість theme. Дана конфігурація буде знаходитись в каталозі fw/base/theme, яка буде відповідати за те, як саме будуть замінені елементи відображень та як буде мати власну змінну $basePath в якій буде вказаний базовий каталог, в якому буде розміщена інформація про css, javascript та зображення.