Дані та Подання «проблема роз’єму»
Предметна логіка перш за все потрібна у спілкуванні з відвідувачами, а таке спілкування починається з Віду. Тому створюватимемо Товсті Тупі Потворні Шаблонізатори!
Дані та Подання: «проблема роз'єму»
Це продовження дослідження, розпочатого у статті http://dn.ir2.ru/asimmet.aspx.
Шаблон проектування Дамп (Dump) або Калька
Редакторmmedit (Mysql Mini Editor) відображає не лише таблиці, а й взагалі будь-які запити, що повертають ресурс. Він відповідає одному з головних принципів фреймворку – повна байдужість до даних (бази даних і таблиці в межах mysql можна замінювати як завгодно). Це ідеальна схема спілкування Даних та Подання (коли все всім пофіг, ніхто ні про кого нічого не знає).
Що робити, коли вивести дані в HTML треба не однорідно (як осередки таблиці), а довільно, наприклад, як у каталозі посилань irweb.ir2.ru:
– коли у першому рядку три елементи (Посилання на сайт, Місто, Дата), у другому – один (Короткий опис), у третьому – два (Посилання на повний опис, Розділ)? Можна вперто намагатися застосувати той самий Дамп-Кальку – наприклад, упаковавши кожен із елементів у тегиp і призначивши частини їх стилі float:left , а інший частини float:right . В принципі це можливо. Про плаваюче позиціонування мають право не знати ні Дані, ні Шаблонізатор, а займатися ним буде лише Фінішний Шпаклівник – CSS.
Таке відновлення «лінійності», однак, вже пов'язане з додатковою умовністю – порядком виведення полів з mysql-запиту, якщо ми хочемо, щоб, як і раніше, «ніхто нічого ні про кого не знав». А це означає, що комусь дещо доведеться дізнатися. А саме: Подання має частково спрацювати як Екстрактор та видати розпорядження Даним, в якому порядкувиводити поля запиту.
Це можна зробити за допомогою керуючого даними масиву. Нам все одно потрібен буде такий масив – хоча б для українських найменувань полів (у варіанті виведення в таблицю користувача), то чому б заразом не використовувати його і для сортування:
Тепер для виведення даних у потрібному порядку треба просто використовувати foreach не для масиву $ data, а для масиву $ names, а вже потім звертатися за індексом до $ data (хоча такого індексу в $ data, за законом підлості, може і не виявитися -: ).
Проблема роз'єму (асиметрія Даних та Подання)
Всі наші спроби зберегти рівновагу все одно котяться під укіс, тому що частина елементів у нас – посилання, а для виведення одного посилання потрібно більше одного поля даних. Тобто, якщо Дані - електрична розетка, а Подання - вилка, то в розетці буде в даному випадку більше дірок, ніж стрижнів у вилці, - і виникне та сама проблема (поганого) роз'єму, проблема неможливості простої, лінійної стикування:
Одному елементу «Посилання на сайт» у Поданні відповідають два поля в масиві Даних:url іtitle (як і має бути, загалом, для посилання). Досвідчені розробники скажуть: "Ну й у чому проблема?" Просто візьмемо та заповнимо шаблон:
А проблема в тому, що це вже буде не Калька-Дамп, і взагалі ніякий не шаблон проектування (на що, втім, на-ть), але система втратить головну властивість фреймворку - незалежність від матеріалу. Згадування конкретних полів (url, title) пов'язує код по руках та ногах; наступного разу, коли таблиця буде іншою (або знадобиться вивести інші поля з цієї ж), нам доведеться знайти і поміняти цю конкретну ділянку коду (і не один цей). А в ідеальному фреймворку має бути достатньо поміняти тільки mysql-запит (якце відбувається у згаданому вище mmedit).
Варіанти виправлення «Поганого роз'єму»
Варіант 2. Додати до керуючого масиву мітки, що об'єднують по два поля, необхідні створення посилання. Він, власне, не виключає Варіант 1, а доповнює його: частина посилань позначається на підставі "автоматики" - виловлювання пар primary key => name, а інша частина – довільно (з предметної логіки – вимог життя).
Варіант 3. Можна зробити і трохи навпаки: втілити вимоги предметної логіки до структури таблиці (виправити структуру) – замінити в Головній таблиці посилань найменуванняtitle наname (а url і так є первинним ключем ), і тоді Варіант 2 у цьому випадку стане зовсім не потрібен. Але ми не можемо гарантувати, що він не знадобиться для інших довільних об'єднань елементів (не обов'язково посилань).
Керуючий масив
Керуючий даними масив. Ні, керівник перетворенням цих масив належить (ставиться до) уявленню. Масив чи цілий Об'єкт. Що він робить? Він чекає від даних деяких конкретних полів і описує, що з цими полями робити. В ідеалі він чекає на деякі класи полів (як у Варіанті 1 виправлення Поганого роз'єму). У менш ідеальному випадку – конкретні поля. Що буде, якщо цих полів немає в даних? Нічого: обробник масиву звірить Дані з умовами і відправить (перетворені чи ні) Дані далі – шаблонізатор. Тобто це такий гігантськийIF : якщо знаходить, що шукає, переводить Дані у складнішу форму, а у разі відсутності необхідних умов повинен спрацьовувати метод Калька-Дамп (Дані вивалюються у шаблон Подання «не дивлячись», без конкретних імен).
Загальна схема роботи Толстого Потворного Шаблонізатора
1. Найголовнішийшаблон (рівня сторінки) вимагає заповнення своїх елементів (принцип екстрактор): $menu = build_menu(); $list_item = build_list(1); //.
2. Функції типу build_menu() за допомогою власного sql-запиту (вони самі визначають його) вилучають Дані з бази (Екстрактор), звіряють Дані зі своїм власним масивом, що управляє, і перетворять у разі виконання деяких умов; передають підготовлені Дані цикл Простого шаблонизатора (працюючого за принципом Дамп-Калька); повертають готовий HTML свого рівня.
Гм. А що робить орган роботи з Даними (і колись)? І що робить Художній Контролер (ХК)? Ну, ХК, припустимо, розбирає УРЛ і на основі отриманих результатів вибирає найголовніший шаблон (тип сторінки, що виводиться). А орган роботи з даними підключається в той момент, коли дрібні будівельні функції намагаються щось отримати з бази. Або не підключається, якщо потрібний масив даних вже отримано (і збережено, закешовано) іншою функцією.
Робота з Даними – це робота з БД (типу CRUD). А де ж Предметна Логіка (бізнес-логіка, як кажуть срані буржуї)? Зрозуміло, що у бізнес-шарі. і ще в тому, що ми перейменували полеtitle у полеname. І що взагалі вирішили виводити частину інформації із БД у вигляді посилань. А рішення це втілено десь у глибині однієї з будівельних функцій, що працює на Подання (на наш ТТУШ).
Що невірно? ;-) А ось і правильно :-Р. Логіка перш за все потрібна у спілкуванні з відвідувачами, а таке спілкування починається з Віду. Жодна веб-студія кроку не зробить по функціоналу без затвердження дизайну. Усі на службу ТТУШ!