Технічне завдання (ТЗ) - це визначення кінцевого результату і мети вашого проекту. Розробка ТЗ - це документ, який буде відповідно оформлений і використаний власником проекту та учасниками проекту.
Fluid 3.0: Огляд семінару і важливі оновлення для користувачів
В міру того, як нові функції будуть завершені, я доповню їх короткими спеціалізованими статтями, які дадуть розробникам і користувачам знання про те, чого очікувати при оновленні до Fluid 3.0, а також надихнуть вас на нові способи структурування ваших проектів з використанням Fluid.
У нас було дві основні теми на семінарі:
- Документація
- Розробка: зокрема, скорочення і об'єднання API-інтерфейсу Fluid для розробників і користувачів.
Перш за все, я хотів би подякувати Systime за їх давню відданість TYPO3 і за щедру пропозицію гостинності, часу, їжі і всіх зусиль, які були спрямовані на координацію семінару! Ще одне спасибі Unikka за спонсорування раунду піци і Феліксу Якобі за спонсорування кави для наших учасників. Моя компанія, NamelessCoder, спонсорувала відвідування ресторану, але це я кажу спасибі учасникам, а не навпаки.
Огляд і результати семінару Fluid 3.0
Поліпшення документації Fluid
- Ми вибрали стратегію використання цільової сторінки і розділили документацію Fluid на дві основні частини: швидка документація по початку роботи для залучення нових користувачів і ознайомлення їх з синтаксисом і т.д. І більш велика документація по API для старих і нових розробників, яким потрібно розширити Fluid такими речами, як ViewHelpers
- Ми досліджували, як поліпшити файли XSD, згенеровані Fluid, за допомогою документації ViewHelper, щоб бути набагато більш інформативними і точними щодо типів аргументів (додавання таких речей, як імена класів PHP, стандартний набір властивостей XSD, таких як string, integer і т . Д.)
- Ми також обговорили рендеринг додаткової документації Fluid в файли XSD. Наприклад, маніфест файлів шаблонів і їх обов'язкові аргументи
- Ми коротко торкнулися стратегії документування відмінностей, які будуть представлені в Fluid 3.0, таким чином, щоб їх було легко використовувати для будь-якого мігруючого. Наприклад, надаючи їм документ типу «якщо ви зробили це раніше, вам потрібно зробити це зараз», щоб перерахувати нові практики, які 1:1 замінюють старі практики.
Покращення в розробці Fluid
- Ми ввели строгі типи в максимально можливій кількості місць з найменшою кількістю критичних змін для користувачів. Ця робота також виявила ряд невеликих проблем з тестами, і дозволила нам поліпшити як код, так і тести.
- Ми вдосконалили рішення, щоб замінити використання регулярних виразів в Fluid. Історично склалося так, що на Fluid вплинуло кілька проблем, пов'язаних з регулярними виразами, та недавно була виявлена пара серйозних проблем. Нове рішення більше не буде використовувати регулярні вирази для поділу шаблонів, замість цього буде реалізовано набагато більше лінійне і незалежне від платформи рішення. Це нове рішення також полегшує кілька нових функцій, які будуть описані більш детально пізніше
- Ми обговорили можливі життєздатні альтернативи досить складною логікою, яку Fluid використовує для компіляції шаблонів в класи PHP, що, в свою чергу, дозволило б спростити ViewHelpers, щоб більше не розрізняти скомпільовані / некомпіліровані стану виконання, і, в свою чергу, зменшити складність API- інтерфейсів ViewHelpers.
- Потім ми почали роботу з уніфікації внутрішнього API Fluid. Ця робота є попередником деяких важливих функцій Fluid 3.0, наприклад, параметрезованих шаблонів і розділів. Ми не змогли закінчити цю частину, але продовжуємо цю тему після семінару
- Ми підготували перейменування пакету Fluid Composer в Typo3 / Fluid-Engine. Щоб отримати більше інформації, стежте за цими змінами!
Після семінару я продовжив працювати над усім, що обговорювалося і планувалося під час сесії. Ця робота в даний час майже завершена і в підсумку стала більш-менш повної листуванням кожної частини Fluid з нуля.
Заглядаючи вперед: Fluid 3.0 Застарілі і кращі практики
Це означає, що версія 3.0 удосконалює багато застарілих можливостей, і звичайно, все застарілі API тепер мають нові і кращі альтернативи. Застарілі і майбутні кращі практики:
- Сильна зміна для вирішення проблем синтаксичного аналізу: це було найбільш критично, і необхідно було термінова зміна, тому що аналізатор шаблонів був повністю переписаний. Розривна зміна впливає на випадки, коли раніше вам доводилося навмисно порушувати виявлення синтаксичного аналізатора. Наприклад, при написанні об'єктів JS може знадобитися виконати щось на зразок <f:format.raw>{</f:format.raw>, щоб уникнути відкривання фігурних дужок. Зверніть увагу, що це конкретне використання тепер викликає помилку синтаксичного аналізу! Це впливає тільки на цей варіант використання і тільки при використанні на що відкриває фігурної дужки. Якщо ви використовували його навколо закриваючих фігурних дужок, не повинно бути ніяких проблем. Причина в тому, що синтаксичний аналізатор Fluid тепер чутливий тільки до послідовності і не може бути навмисно порушений вкладеними тегами. В майбутньому, вбудовані вирази, які не потрібно аналізувати як Fluid, можна екранувати, просто додавши зворотну косу риску попереду. Наприклад, запис \{ "foo":"bar"} означає, що вміст curlies буде сприйматися буквально як рядок.
- Fluid більше не використовує кешування. Область дії Compiler видалена, і методи compile() більше не будуть викликатися. Версії шаблону класу PHP не створюються, і в шаблоні використовується тільки одне подання шаблону або компонента (ViewHelper або інше). Це також означає, що немає розігріву кешу: можуть бути додані нові методи для настройки Fluid з повними картами класів і файлів, щоб зробити пошук статичним, але вплив буде незначним.
- Вся концепція різних частин, макетів і шаблонів застаріла. Ця тристороння концепція зводиться до однієї концепції: Atoms. Нова концепція служить тієї ж мети, що і часткові варіанти і макети.
- Вся область уявлення - інтерфейси, абстрактні класи і клас TemplatePaths - застаріли. Fluid 3.0 більше не буде нав'язувати будь-які рішення про те, як буде відображатися шаблон. Вся ця область дії замінюється класом FluidRenderer, який приймає ім'я файлу в якості точки входу. Тільки файл і контекст, ніякої орієнтації MVC або чого-небудь ще. Це в поєднанні з концепцією Atoms повністю замінює старе дозвіл шаблонів Fluid і макетування / часткове використання.
- Більше немає шаблонних препроцесорів, а сама функція видалена.
- ViewHelpers повністю перероблений і пропонує безліч нових можливостей. Найбільш важливою зміною є видалення застарілих властивостей «templateVariableContainer» і «viewHelperVariableContainer», які тепер повинні бути доступні через RenderingContext.
- Методи render() і renderStatic() для ViewHelpers тепер вважаються застарілими. Замість цього ViewHelpers може реалізовувати метод evaluate (), який приймає аргумент RenderingContext. Це буде впровадження найкращої практики в майбутньому
- Починаючи з версії 3.0 використання render() або renderStatic() призводить лише до витрат при виконанні, з точки зору циклів CPU і обсягу пам'яті.
- Базовий клас для ViewHelpers все ще існує, але тепер він є необов'язковим. Тепер він надає тільки службові методи і підтримку старих методів ViewHelper, таких як render(). ViewHelper може тепер розширювати AbstractComponent або взагалі не використовувати базовий клас, а потім повністю змінювати кожен метод API
- InterceptorInterface був видалений. На перехоплення більше не можна впливати, наприклад, без його реалізації в якості ViewHelper. Екранування тепер є вбудованої і включеної за замовчуванням функцією, яку необхідно явно відключити при налаштуванні.
- Вирази більше не відокремлені від ViewHelpers. ViewHelper може реалізувати новий інтерфейс, щоб сигналізувати, що він також працює як вираз (наприклад, вирази math {foo + 1}), і коли Fluid аналізує вираз, він просто створює відповідний екземпляр ViewHelper. Це означає, що ViewHelper працює як вираз і як ViewHelper. Наприклад, Math працює як {foo + 1}, але також як {f: expression.math (a:foo, b:1, operator:'+')} для більш складних випадків використання.
- Це не зовсім видалення або старіння: екранування лапок у вкладеному вбудованому синтаксисі більше не потрібно взагалі. Fluid 3.0 ігнорує таке екранування і тому сумісний, але нові шаблони можуть бути написані незалежно від екранування лапок. Послідовність сама по собі має значення, тобто ваші пари лапок повинні збігатися, але ви можете використовувати однаковий тип лапок на всіх рівнях вкладеності.
- Існують і інші не згадані тут винятку, але всі вони впливають на API, який ніколи не вважався дійсно загальнодоступним.
Використання заміщених функцій
К сожалению, устаревание и удаление были довольно серьезными для всего, кроме самого важного контекста: самого файла шаблона. Насколько это возможно, практика написания шаблонов не изменилась, но есть несколько довольно важных воздействий в виде измененных элементов, которые должны использоваться по-разному. Это:
- Атоми (Atoms) це нова концепція, щоб замінити частини (partials) і макети (layouts). Атом може працювати як макет, і як частина, в залежності від того, що він містить і де він використовується. Атоми реєструються так само, як ViewHelpers, щоб належати простору імен, і кожен простір імен потім має кілька шляхів файлової системи, де буде виконуватися пошук. Коли Atom використовується в шаблоні, який не містить нічого, крім розділів, він працює як макет сьогодні. Коли використовується десь усередині шаблону, він працює як частина. Основна відмінність полягає в тому, що Atom можна створити так, щоб він містив тільки розділи, і при використанні це призводить до того, що розділи імпортуються в поточний шаблон (і можна перезаписувати, визначаючи нові розділи з тим же ім'ям). Практичні приклади цієї нової концепції будуть представлені перед випуском. Суть в тому, що f:layout і f:render застаріли, як і partialRootPaths, і всі інші колекції шляхів до шаблонів.
- Наприклад, Atom може існувати в res/atoms/myAtom.html. Реєстрація простору імен Atom «foo» шляхом res/atoms/ означає, що <foo: myAtom> в Fluid відображає або імпортує шаблон і розділи всередині, або змушує його працювати так само, як сьогодні працює макет. Ці масиви шляхів підтримують кілька шляхів і можуть бути розширені таким же чином, як «часткові шляху», як розширюються сьогодні.
- Рідко використовувані перемикачі, такі як {escape-off}, тепер повинні бути записані як {@escaping off}, інакше вони будуть ігноруватися. Ризик їх фактичного використання в реальних проектах дуже низький, і ви відразу дізнаєтеся, чи впливає це на вас. Єдиний виняток - {namespace xyz = Foo\Bar}, яке має спеціальну обробку (застаріло, видалено в 4.0). У майбутньому вони повинні бути записані як {@namespace xyz = Foo\Bar}
- Витяг простору імен з (X) вузлів HTML тепер працює тільки для тегів <html>, але, крім цього, воно працює точно так само, як і раніше. Якщо ви використовували <div xmlns: f = "...">, вам потрібно буде замінити його на <html>
Доброю новиною є те, що існує неймовірна кількість нових функцій синтаксису, які повністю сумісні зі старим синтаксисом, але надають безліч нових способів оголошення масивів, спрощеного вбудованого синтаксису, обробки ванільних (X) HTML-тегів. з класами ViewHelper і багато іншого.
Демонстраційний репозиторій буде створено набагато раніше випуску 3.0, який можна клонувати і редагувати для вивчення всіх нових функцій Fluid.
Реліз Fluid 3.0 в даний час не запланований. Передбачається, що він не буде використовуватися в v10 LTS і, швидше за все, не стане залежністю від TYPO3 до розробки v11, що слід майже відразу після випуску v10 LTS.
Я сподіваюся, що ви тепер добре поінформовані і повідомлені про всі позитивні події для Fluid 3.0. Подивіться інші статті для користувачів Fluid 3.0.
Ви також можете вивчити огляд семінару від команди документації для отримання додаткової інформації.
Вичитування: Amy Hunt