Приставки за ден 20 (1)
Вчера научихте как да интернационализирате и локализирате вашите Symfony приложения. Още веднъж, благодарение на стандартите на ICU и многото помощници, рамката на Symfony прави това наистина лесно.
Днес ще говорим за плъгини: какво представляват, какво можете да опаковате в плъгин и за какво могат да се използват.
Symfony плъгин
Приставката Symfony предоставя начин за пакетиране и разпространение на подмножество от файловете на вашия проект. Подобно на проект, плъгинът може да съдържа класове, помощници, конфигурация, задачи, модули, схеми и дори стилове (CSS) и картини.
Частни плъгини
Като начало, приставките се използват, за да улеснят споделянето във вашите приложения или дори в проекти. Спомнете си, че приложенията на Symfony споделят само модел. Приставките предоставят начин за споделяне на повече компоненти между приложенията.
Ако трябва да използвате повторно същата схема за друг проект или същите модули, преместете ги в приставка. Тъй като приставката е просто папка, можете да ги включите сравнително лесно, като създадете SVN хранилище с помощта на svn:externals или просто като копирате файлове от един проект в друг.
Наричаме тези добавки „частни“, защото използването им е ограничено до един разработчик или компания. Те не са публично достъпни.
Можете дори да пакетирате личните си плъгини, да създадете свой собствен канал за плъгини в Symfony и да ги инсталирате с помощта на задачата за инсталиране на плъгин.
Публични добавки
Публичните добавки са достъпни за изтегляне и инсталиране от цялата общност. По време на този урок използвахме няколко публични добавки: sfGuardPlugin и sfFormExtraPlugin.
Абсолютно еднакви сакакто и частни добавки. Единствената разлика е, че всеки може да ги инсталира за своите проекти. По-късно ще научите как да публикувате и хоствате публични добавки на уебсайта на Symfony.
Различни начини за организиране на код
Има и друг начин за възприемане и използване на плъгини. Забравете за повторно използване и споделяне. Добавките могат да се използват за организиране на вашия код по различен начин. Вместо да организирате файлове по нива: всички модели в папката lib/model/, шаблони в папката templates/, . ; файловете са групирани по функционалност: всички свързани с работата файлове заедно (модел, модули и шаблони), всички CMS файлове заедно и т.н.
Файлова структура на плъгина
Плъгинът е просто структура на файлови папки, организирана по определен начин въз основа на характеристиките на файловете. Днес ще преместим по-голямата част от кода, който написахме за Jobeet, в sfJobeetPlugin. Опростеното оформление, което ще използваме:
Jobeet плъгин
Първо, нека просто създадем нова папка в plugins/. За Jobeet, нека създадем папка sfJobeetPlugin:
След това активирайте sfJobeetPlugin във файла config/ProjectConfiguration.class.php.
Всички имена на добавки трябва да завършват с Plugin. Също така е добър навик да ги поставяте с префикс sf, но това не е задължително.
Първо преместете файла config/schema.yml в plugins/sfJobeetPlugin/config/:
Всички командни редове са дадени за Unix-подобна среда. Ако използвате Windows, можете да плъзгате и пускате файлове в Explorer. И ако използвате Subversion или някакъв друг инструмент за управление на код, използвайте предоставените вградени инструменти (напр. svn mv за преместване на файлове).
Преместване на файлове с модели, форми ифилтри в plugins/sfJobeetPlugin/lib/:
Премахнете файла plugins/sfJobeetPlugin/lib/form/BaseForm.class.php.
Ако сега изпълните задачата propel:build-model, Symfony ще генерира файлове в lib/model/, но това не е, което искаме. Изходната папка за Propel може да бъде персонализирана чрез добавяне на опцията за пакет. Отворете schema.yml и добавете следната настройка:
Сега Symfony ще създаде тези файлове в папката plugins/sfJobeetPlugin/lib/model/. Конструкторът на формуляри и филтри също приема тази настройка по време на генериране на файл.
Задачата propel:build-sql генерира SQL файлове за създаване на таблици. Тъй като файловете са именувани по същия начин като пакетите, премахнете текущия файл:
Сега, ако стартирате propel:build-all-load, Symfony ще генерира файлове в папката lib/model/ на приставката, както се очаква:
След изпълнение на задачата проверете дали папката lib/model/ не е създадена. Задачата обаче създаде папките lib/form/ и lib/filter/. И двете включват базови класове за всички форми на Propel във вашия проект.
Тъй като тези файлове са глобални за проекта, премахнете ги от приставката:
Ако използвате Symfony 1.2.0 или 1.2.1, класът на филтъра за основна форма се намира в папката plugins/sfJobeetPlugin/lib/filter/base/.
Можете също да прехвърлите файла Jobeet.class.php към плъгина:
Тъй като преместваме файлове, изчистете кеша:
Ако използвате PHP ускорител като APC и се случи нещо странно по време на тази стъпка, рестартирайте Apache.
След като всички файлове на модела са преместени в приставката, изпълнете тестовете, за да се уверите, че всичко работи:
Контролери и изгледи
Следващата логична стъпка е да преместите модулите в плъгина. За да предотвратите сблъсъци в имената на модулите, добра идея е да добавите къмимето на модула има същия префикс като името на приставката:
За всеки модул трябва също да промените имената на класовете във всички файлове actions.class.php и components.class.php (например класът affiliateActions трябва да бъде преименуван на sfJobeetAffiliateActions).
Извикванията към include_partial() и include_component() също трябва да бъдат променени в следните шаблони:
- sfJobeetAffiliate/templates/_form.php (променете партньор на sfJobeetAffiliate)
- sfJobeetCategory/templates/showSuccess.atom.php
- sfJobeetCategory/templates/showSuccess.php
- sfJobeetJob/templates/indexSuccess.atom.php
- sfJobeetJob/templates/indexSuccess.php
- sfJobeetJob/templates/searchSuccess.php
- sfJobeetJob/templates/showSuccess.php
- apps/frontend/templates/layout.php
Актуализирайте действията за търсене и изтриване:
Сега актуализирайте файла routing.yml, за да приложите тези промени:
които казват, че модулите не са активирани. Тъй като плъгините са общи за всички приложения в даден проект, трябва специално да включите модулите, от които се нуждаете за дадено приложение, в неговия файл settings.yml:
Последната стъпка от миграцията е да коригираме функционалните тестове, където тестваме името на модула.
Задачите могат да бъдат преместени в плъгина достатъчно лесно:
i18n файлове
Плъгинът може също да съдържа XLIFF файлове:
Маршрутизиране
Плъгинът може също да съдържа правила за маршрутизиране:
Уеб съдържание
Потребител
Преместването на методите на клас myUser, които се занимават с хронологията на работата, е малко по-сложно. Можем да създадем клас JobeetUser и класът myUser да наследи от него. Но има по-добро решение, особено ако има няколко добавкиискате да добавите методи към класа.
Основните обекти на Symfony уведомяват за събития по време на техния жизнен цикъл и вие можете да ги слушате. В нашия случай трябва да слушаме събитието user.method_not_found, което възниква, когато се извика метод, който не е дефиниран в обекта sfUser.
Когато Symfony се инициализира, всички плъгини също се инициализират, ако имат клас за конфигурация на плъгини:
Известието за събитие се управлява с помощта на sfEventDispatcher, обект за изпращане на събития. Регистрирането на слушател е толкова просто, колкото извикването на метода connect(). Методът connect() свързва името на събитието с извиканите PHP обекти.
Обектът с възможност за извикване на PHP е променлива на PHP, която може да се използва от функцията call_user_func() и връща true, когато се предаде на функцията is_callable(). Низът представлява функция, докато масивът може да представлява метод на обект или метод на клас.
Със следния код обектът myUser ще извиква статичния метод methodNotFound() на класа JobeetUser всеки път, когато не може да намери метод. След това зависи от метода methodNotFound() дали да обработи пропуснатия метод или не.
Премахнете всички методи от класа myUser и създайте клас JobeetUser:
Когато диспечерът извика метода methodNotFound(), той ще предаде обекта sfEvent.
Ако методът съществува в класа JobeetUser, той ще бъде извикан и върнатата му стойност ще бъде предадена на регистратора. Ако не, Symfony ще се опита да намери следващия слушател или ще върне изключение.
Методът getSubject() връща манипулатора на събитието, в този случай обекта myUser.
Структура по подразбиране срещу архитектура на добавки
Използването на архитектурата на плъгина ви дава възможност да организирате кода си по различен начин:
Използване на добавки
Когато започнете да прилагате нова функционалност или ако се опитвате да разрешите класически проблем с уеб програмирането, може би някой друг вече е решил същия проблем и може би е пакетирал решението като плъгин на Symfony. Потърсете публичните плъгини на Symfony в раздела за плъгини на уебсайта на рамката на Symfony.
Тъй като плъгинът е самостоятелна папка, има няколко начина да го инсталирате:
- Използване на задачата за инсталиране на плъгин (работи само ако разработчикът на плъгина е създал пакет с плъгини и го е качил на уебсайта на Symfony)
- Изтеглете пакета и го разархивирайте ръчно в папката plugins/ (имате също нужда от програмиста, за да изтеглите пакета)
- Създаване на svn:externals в добавки/ за приставката (работи само ако разработчикът на приставката хоства приставката в Subversion)
Последните два начина са прости, но им липсва гъвкавост. Първият начин ви позволява да инсталирате най-новата версия в зависимост от версията на Symfony в проекта, лесно да надстроите до най-новата стабилна версия и по-лесно да управлявате зависимостите между добавките.
Създаване на плъгин
Опаковка на плъгини
За да създадете пакет с добавки, трябва да добавите някои необходими файлове към структурата на папките на добавките. Първо създайте файл README в главната папка на приставката и опишете как да инсталирате приставката, какво предоставя и какво не. Файлът README трябва да бъде форматиран във формат Markdown. Този файл ще се използва от уебсайта на Symfony като основна част от документацията. Можете да тествате трансформацията на вашия файл README в HTML с помощта на приставката Symfony dingus.
Задачи за разработване на плъгини
Ако откриете, че създавате частни и/или публични добавки често, възползвайте се от някои от задачите вsfTaskExtraPlugin. Този плъгин, поддържан от основните разработчици на Symfony, включва редица задачи, които да ви помогнат да рационализирате жизнения цикъл на плъгина:
Трябва също така да създадете файл ЛИЦЕНЗ. Изборът на лиценз не е лесна задача, но само плъгини, пуснати под подобен лиценз на Symfony (MIT, BSD, LGPL и PHP), са показани в раздела за добавки на Symfony. Съдържанието на файла ЛИЦЕНЗ ще се покаже в раздела за лиценз на публичната страница на вашия плъгин.
Последната стъпка е да създадете файл package.xml в основната директория на плъгина. Този файл package.xml следва синтаксиса на пакета PEAR.
Най-добрият начин да научите синтаксиса package.xml е да го копирате от съществуващ плъгин.
Както можете да видите в този пример, файлът package.xml се състои от няколко части:
Етикетът съдържа файловете, които трябва да бъдат поставени в пакета:
Тагът указва всички зависимости, които плъгинът може да има: PHP, symfony и други плъгини също. Тази информация се използва от задачата plugin:install за инсталиране на най-подходящата версия на приставката за средата на проекта и също така инсталира приставки, изисквани от зависимости, ако има такива.
Винаги трябва да указвате зависимост от Symfony, както направихме тук. Декларирането на минимална и максимална версия позволява на задачата plugin:install да знае коя версия на Symfony е необходима, тъй като различните версии на рамката имат много различни API.
Възможно е също така да декларирате зависимости от други добавки:
Маркерът не е задължителен, но дава полезна информация за промените между изданията. Тази информация също е достъпна в раздела Changelog и в емисията на приставките.
Хостинг на добавки на уебсайта на Symfony
Вие автоматично ще станете администратор на приставката и ще видите раздел „администратор“ в интерфейса. В товаще намерите всичко необходимо за управление на вашия плъгин и изтегляне на вашите пакети.
Често задаваните въпроси за приставките съдържат много полезна информация за разработчиците на приставки.
Ще се видим утре!
Създаването на добавки и споделянето им с общността е един от най-добрите начини да допринесете за проекта Symfony. Толкова е просто, че хранилището на плъгини е пълно с полезни, забавни и понякога нелепи плъгини.
Symfony™ е търговска марка на Symfony SAS. Всички права запазени.