Поиск в системе

Не надо обладать десятилетним опытом создания интернет сообществ, чтобы понимать простую истину - коробочный продукт разрабатывается для удовлетворения требований большинства потребителей. А значит, задача по расширению стандартных возможностей системы возникнет перед каждым владельцем сообщества. Мы приложили все наши знания и опыт в создании и сопровождении сообществ для эффективного решения этой задачи. Проблемы модификации в современных платформах Будучи активными разработчиками сообществ на основе готовых решений (vBulletin, IP.Board, phpBB) мы постоянно сталкивались с проблемами в разработке, но, пожалуй, самая досаждающая из них - отсутствие возможности безболезненно для ядра системы вносить изменения в ее базовое поведение. Решение данной проблемы, как правило, выливается в необходимость внесения изменений в файлы самой системы, что влечет за собой проблемы при обновлениях. Если такие изменения глобальны, то актуализация скриптов ядра системы становится фактически непосильной задачей (прощайте исправления ошибок, оптимизации и новые возможности). http://altervega.ru/forums/upload/forum/2012/03-19/a42fb8aa9cffc5937fe0c2a5de5f7d85.jpeg Есть проблемы и поменьше, вроде отсутствия удобного внутреннего API, запутанности логики приложения и отсутствия документации. Но они не так сильно влияют на разработку, как выше описанная. Конечно, перечисленные решения представляют механизмы расширения, однако, они являются несколько инородными, так как изначально не закладывались в архитектуру системы, а добавлялись уже в готовую. Итак перед нами стояла задача сделать AlterVega гибкой и расширяемой настолько, чтобы разработчик мог ее улучшить без последствий для самой системы. Первые шаги в решении этой задачи были предприняты еще на этапе проектирования архитектуры системы. В качестве основы мы выбрали идею реализации веб-приложения на основе паттерна Model-View-Controller (MVC). А при дизайне классов системы мы придерживались SOLID принципов и необходимых уровней их связанности (Low Coupling and High Cohesion). После того как у нас появился работающий прототип системы, мы попробовали нарастить его возможности, при этом не нарушив концепции, заложенной в архитектуру приложения. В результате чего у нас появился Dependency Container. Dependency Container (DC) Контейнер предоставляет внешние зависимости программному компоненту системы. Контейнер гибко настраивается, что позволяет разработчикам управлять зависимостями в ходе расширения системы. Например, при построении списка тем у нас выводится их рейтинг. Работа с рейтингом вынесена в отдельный программный компонент, потому для компонента вывода списка тем он является внешней зависимостью. /* Получение рейтинга темы и проверка голосования за неё */ $rating_service = $this->_services->get( 'forum.thread.rating' ); $rating_service->fill( array( $thread ) ); Здесь сервис рейтинга получается из контейнера. В настройках контейнера есть запись: <service id="forum.thread.rating.strategy" shared="false"/> <service id="forum.thread.rating"> <argument type="service" id="forum.thread.rating.strategy"/> </service> Разработчик может просто поменять описание сервиса рейтинга, например, добавив кеширование: <service id="forum.thread.rating.strategy" shared="false"/> <service id="forum.thread.rating.base"> <argument type="service" id="forum.thread.rating.strategy"/> </service> <service id="forum.thread.rating"> <argument type="service" id="core.cache" /> <argument type="service" id="forum.thread.rating.base"/> </service> При условии, что класс MyPlugin_Service_Cached_Rating будет реализовывать необходимый для сервиса рейтинга интерфейс, система начнет работать уже с кешируемым рейтингом. Как видно, настройка контейнера позволяет изменять базовые классы системы, что дает возможность без изменения базового кода, менять базовое поведения системы. Следующим шагом стало добавление инструментария для расширения возможностей системы. Если на шаге с внедрением контейнера мы преследовали возможность изменить существующее поведение, то на этом - добавить новое. Здесь уже нужна система не подмены существующих классов и объектов, а их расширение. Система расширения классов Мы отталкивались от того, что расширений даже для одной конкретной возможности может быть несколько, а авторы могут не знать друг о друге. Замена имени класса в настройках DC обеспечивает возможность существования только одного расширения. Это нам не подходит. Мы усовершенстовали наш контейнер, добавив возможность расширять базовый класс, классами расширений. Выглядит это так: <service id="user"> <argument type="service" id="user.mapper"/> <extended by="Author1_MyPlugin_Service_User"/> <extended by="Author2_MyPlugin_Service_User"/> <extended by="Author3_MyPlugin_Service_User"/> </service> В итоге базовый класс сервиса User_Service_User будет обладать наряду со своими обычными возможностями и всеми возможностями из классов Author1_MyPlugin_Service_User, Author2_MyPlugin_Service_User и Author3_MyPlugin_Service_User. Имеющиеся методы модифицирования позволяют изменять и добавлять новые возможности. Однако такие изменения работают на основе полиморфизма, а значит, если нам потребуется поменять поведение метода класса, например, в середине, то нам потребуется скопировать части базового кода. В результате появляется зависимость модификации от базового кода, что при изменении этого кода приведет к поломке или неверной работе модификации. Для решения данной проблемы мы сделали еще один шаг в развитии нашей системы модифицирования - добавили событийную систему в базовые классы приложения. Система событий Идея заключается в том, что при изменении состояния одного из объектов все зависящие от него оповещаются об этом событии. Соответственно зависящие объекты при наступлении определенных событий могут выполнять какие-то действия. Например, при добавлении нового комментария в тему, в систему событий поступает уведомление об этом. На событие добавления комментария подписаны модуль рассылки уведомлений и модуль пересчета рейтинга, которые рассылают уведомления подписавшимся на тему, и пересчитывают рейтинг авторам темы и комментария, соответственно. В коде это выглядит так: Порождение сигнала о создании нового входящего сообщения в личной почте $signals->emit( 'user.before.message.inbox.created', $message ); Один из подписчиков на данное событие, уведомляющий пользователя о создании личного сообщения и заносящий это событие в ленту обновлений /** * Класс слушателя событий личных сообщений */ class User_Class_Signal_Listener_Message extends jE_Signal_Listener_Abstract { /** * Запись события в ленту обновлений * * @param jE_Signal $signal Данные для обработки сигнала или объект сигнала * @return jE_Signal */ public function afterCreate( jE_Signal $signal ) { $message = $signal->getData(); $dc = jE::dc(); $dc->get( 'user.message.log' )->logEvent( $message ); $dc->get( 'user.message.notify' )->notify( $message ); return $signal; } } Подписчики на события добавляются разработчиками через конфигурационный файл /_protected/resources/configs/listeners.php. Указывается событие, класс обработчика и метод класса для обработки события 'user.after.message.inbox.created' => array ( 'User_Class_Signal_Listener_Message' => 'afterCreate', ), Порождение сигналов сделано в основных местах создания, изменения, удаления сущностей. К сожалению, внесение инструкций для порождения сигналов требует измений в базовом коде, поэтому мы открыты для добалений таких точек в базовый код. Как вы видите, AlterVega обладает рядом существенных способов изменения и расширения базового поведения системы без редактирования кода базовых классов. До недавнего времени они оставались всего лишь способами, но мы сделали описательный формат, позволяющий собирать изменения в модификации, и внедрили механизм подключения модификаций из директории ресурсов. Поставка модификаций Файлы классов модификации должны храниться в папке /_protected/resources/plugins/. Каждая модификация хранится в отдельной директории с именем модификации. Модификация поставляется с конфигураций config.xml, расположенный в директории модификации. Пример файла конфигурации: <?xml version="1.0" encoding="UTF-8"?> <plugin> <name>Название модификации</name> <author>Автор модификации</author> <config> <signals> Список обработчиков системных сигналов </signals> <services> Список новых объектов контейнера служб </services> <extensions> Список расширяемых объектов контейнера служб </extensions> <includes> Список модификаций шаблонов </includes> <tasks> Список новых задач </tasks> <settings> Список новых настроек </settings> </config> </plugin> Для дистрибуции модификации достаточно запаковать директорию с классами и ресурсами модификации. Администраторы сообществ через администраторский центр смогут импортировать данный архив с модификацией и он автоматически будет развернут и подключен к системе. Администратор также сможет отключать или полностью удалять установленные модификации. Прототип интерфейса можно увидеть на скриншоте http://altervega.ru/forums/upload/forum/2012/03-19/ebe0e2cdb73909cc385093475f748a03.png Планы Система модификаций уже внедрена в основную ветку разработки и будет выпущена в версии 1.1. С помощью модификаций вы сможете изменить большую часть классов компонентов системы, в дальнейших планах у нас доведение этого показателя до 100%. И, конечно же, мы хотим выслушать все вопросы, предложения и пожелания по данной системе, а так же точкам обработчиков системных событий.

Вообщем не знаю от чего плясать, ибо не настолько знаком с php и движком IPB как программист ( ну на самом деле пока в этом деле чуть больше 0ля) но необходимость есть в следующем скрипте : функция первая: новая вкладка редакторе профиля пользователя в которой 2 графы загрузки изображений, каждой из граф соответствует отдельная папка , в данном случае /__/upload/skins и /__/upload/cloak. Изображения должны иметь ограничения на загрузку по размеру и формату ( 64х32 *.png) . Скрипт должен менять родное название картинки на имя пользователя (с сохранением регистра , цеплять соответственно из таблици members переменную "name") Пример: Исходное изображение : megakrytojplash.png => /__/upload/cloak/grim.png . (не обязательно , но желательно добавить предпросмотр в 2d (есть исходник) или 3D при помощи java ( ниже) Функция вторая: На старнице просмотра пользователя необходима интеграция еще одного поля ( под , напротив аватара) с java просмотрщиком этих скинов ( исходник Java есть, его только нужно встроить) Функция третья: не обязательно, но приятно. в просмотре тем в столбике и с информацией пользователя миниатюра того же Java скрипта. так чтобы она была размером с аватарку (можно статичный размер 120х120) . Движок 3.2 В качестве исходника есть работающий независимый php скрипт . Евгений Grim. skype: desscreamer1. или в ПМ ( лучше скайп) приму безвозмездно помощь в написании или консультацию "куда смотреть" ну или готовое решение - цена договорная.

Новые точки входа для хука данных Добавлено несколько новых точек входа в IP.Board, а также приложения. Вот список добавленных в 3.1.3: IP.Board topicViewQuery: позволяют получить дополнительные поля из таблицы members, а также сделать JOIN таблицам из базы данных при получении сообщений из базы. Основное назначение точки - получение информации для вывода в шаблоне userInfoPane. incrementUsersPostCount: покрывает необходимость изменения данных при увеличении счетчика сообщений пользователя (например: популярные модификации начисления очков). [*]IP.Calendar Добавление события Изменения события [*]IP.Blog Добавление записи Добавление записи: Запись Добавление записи: Данные опроса Добавление записи: Данные записи Добавление записи: После добавления опроса Добавление записи: Обновление запроса Добавление комментария Изменение комментария [*]IP.Downloads Добавление файла Изменение файла Обновление данных категории Обновление кеша статистики архива Добавление комментария Изменение комментария Другие приложения, такие как IP.Gallery, также увидят новые точки входа для хука данных. Поддержка хука библиотек В IP.Board 3.1.0 был добавлен новый тип хуков - Хук библиотек. Данный тип хуков, позволяет переопределять существующие библиотеки, а также добавлять в них любую функциональность. Это очень мощный инструмент, пришедший на помощь разработчикам. Первоначально область работы данного типа хуков была ограничена, часть классов попадала под его действие, часть нет. В IP.Board 3.1.3 мы постарались максимально расширить эту область. А так же все наши приложения теперь поддерживают данный тип хука. Хотя в IP.Board 3.1.3 хук поддерживает существенно больше классов библиотек, однако, мы продолжим работу над его улучшением и в версии IP.Board 3.2 хотим прийти к показателю 100% покрытия системы. Новая функция IPSLib::loadActionOverloader() Хуки перезагрузки действий, как правило, выполняются автоматически, но это правило выполняется только при запуске напрямую, если же класс подключается и действие из него выполняется из другого класса (т.е. вручную), то хуки не работают. Пример подключения: require_once( IPSLib::getAppDir('core') . '/modules_admin/languages/manage_languages.php' ); $langLib = new admin_core_languages_manage_languages( $this->registry ); Для решения этой проблемы, мы добавили новую функцию в IPSLib, которая работает аналогично IPSLib::loadLibrary(). Функция принимает только два праметра: первый - путь до самого файла, второй класс, который вы загружаете. Пример: $classToLoad = IPSLib::loadActionOverloader( IPSLib::getAppDir('core') . '/modules_admin/languages/manage_languages.php', 'admin_core_languages_manage_languages' ); $langLib = new $classToLoad( $this->registry ); Прекращение поддержки плагина usercpFormsExt Данный плагин был введен в IP.Board 3.0 и предназначался для расширения панели управления пользователя. Однако с введением хука библиотек данный плагин перестал быть необходимым. Надеемся, что эти небольшие изменения помогут эффективнее расширять возможности IP.Board.

В IP.Board 3 мы представили систему хуков, цель разработки которой уменьшить количество изменений файлов при установке модификаций и сделать их удобными для установки. Мы разработали максимально гибкую систему в основном за счет использования хуков на основе HTML-логики, которая используется фактически при любом выводе контента. Однако мы знали, что еще оставались случаи, когда необходимы были изменение файла, чтобы внести изменения в ту часть системы, которая не является шаблоном или файлом действия. Одной из наших первоначальных целей в IP.Board 3.1 было расширение системы хуков, чтобы уменьшить необходимые изменения файлов, а также упростить их установку. Мы прочитали все отзывы разработчиков модификаций и учли большинство из них в 3.1. Далее краткая информация о сделанных изменениях: Новые типы хуков Нашей первой целью было распространить систему хуков на те части форума, где она до сих пор не была доступной. И теперь мы представляем два новых типа хуков: Хук данных Модификациям часто необходимо иметь возможность добавлять данные в запросы вставки/обновления, которые исполняются IPB, на данный момент решать такую задачу можно только путем запуска дополнительного запроса вставки/обновления самим хуком. Для решения этой проблемы мы добавили новый тип хука, называемый Хук Данных. Он позволяет вам получить массив данных до того, как вы вставите его в базу данных. Например, вы можете создать хук, который будет получать данные сообщений, до того, как вы вставите их в таблицу, это даст вам возможность добавлять любые необходимые данные и изменять сохраненные данные. Кроме того, хук данных может быть использован просто, как точка для запуска своего кода, то есть изменение данных совершенно не обязательно для данного типа хуков. В отличие от стандартных хуков, которые генерируются автоматически, места вызова хуков данных вручную указаны в коде. Если у вас есть пожелания, где бы вы хотели видеть их размещенными, оставьте нам сообщение в этом блоге. На данный момент хуки данных используются в библиотеке создания сообщений, в библиотеке создания личных сообщений и в некоторых местах профиля. Хук библиотек Существует много классов, используемых в IPB , которые недоступны для хуков, так как они не являются действиями или шаблонами. Но часто бывает нужно добавить какие-то свои методы или изменить существующие. Это привело к появлению второго типа хуков, который мы добавили в 3.1 – хуков библиотек. Данный тип позволяет расширить библиотеки, которыми вы пользуетесь через IPB; ярким примером такой библиотеки является class_forum. Метод работы такой же, как у загрузчика действий, ваш хук расширяет выбранную библиотеку и позволяет добавить, или заменить метод на ваш собственный. Вам необходимо вызвать родительский метод, если вы переопределяете метод в хуке. Чтобы позволить данным хукам работать мы внесли изменения в механизм подключения библиотек. Мы постарались изменить большинство существующих мест подключения библиотек на новый тип, но вполне вероятно, что где-то мы забыли это сделать. Другие изменения Хуки в AJAX запросах В версии 3.0 все, что возвращалось с использованием AJAX не проходило через систему хуков. В 3.1 мы устранили этот недостаток и теперь вы можете перехватывать любое содержимое, получаемое через AJAX. Экспорт CSS файлов Эта новая возможность при экспорте хуков, позволяющая вам устанавливать CSS файлы, которые используются данным хуком. CSS файлы могут быть включены в xml хука, а затем импортированы вместе с хуком и сохранены в файловую систему. Доступ к данным функции Один из часто встречающихся запросов - это способ получить данные, передаваемые в функцию шаблона, в IP.Board 3.1 это стало возможным. Активные хуки имеют доступ к данным функции через специальный атрибут класса - functionData. Для сбережения ресурсов, данные сохраняются только для функций, имеющих активные хуки. Пример того, как получить доступ к данным функции topicViewTemplate: Описание функций: function topicViewTemplate($forum, $topic, $post_data, $displayData) { Все эти данные будут доступны вашему хуку через функцию $functionData: $this->registry->output->getTemplate('topic')->functionData['topicViewTemplate']['forum'] $this->registry->output->getTemplate('topic')->functionData['topicViewTemplate']['topic'] В заключение Мы также сделали несколько незначительных настроек в системе хуков, включая обновления интерфейса панели управления администратора, расширение функциональных возможностей, схему быстрого отключения/включения всех хуков, изменение позиции хуков с возможностью IN_DEV и другие. Оригинал статьи: http://community.invisionpower.com/blog/1174/entry-3884-ipboard-310-dev-update-hook-system/