Когда мы открыли исходники РосЯмы, я ожидал одну тему возмущения общественности — что мы сделали её на Битриксе, и что теперь для того, чтоб РосЯму у себя развернуть, надо покупать этот самый Битрикс. Вторая, менее ожидаемая тема возмущения общественности — это то, что разработчики в Гринсайте пользуются mercurial, а не git. Как я уже говорил, существуют определённые организационные трудности с этим. Не буду выносить сор из избы и вдаваться в подробности, просто уточню, что рано или поздно все эти вопросы будут решены, и всё будет ништяк. У РосЯмы будет один официальный репозиторий на github.com, откуда изменения, предложенные сообществом, через тернистый путь всяческого тестирования и утверждения будут попадать на промышленный сервер. Когда-нибудь так будет.
А по первому пункту, про Битрикс, я более подробно расскажу. РосЯмы сделана как модуль Битрикса, кроме того, есть ещё росямовские компоненты и шаблон. Более того, РосЯма впаяна и в админку битрикса. Вообщем, она довольно плотно туда интегрирована, и, как я уже говорил, выкорчевать её из Битрикса для того, чтоб перенести на какую-нибудь другую платформу, будет непросто. Но возможно. Любой желающий может сделать битрикс-фри форк проекта и попытаться перенести РосЯму на другую платформу. И столкнуться с несколькими трудностями.
Первая трудность — именно выкорчёвывание. Некоторая часть функционала РосЯмы очень плотно привязана к Битриксу и без него работать не будет, эти части придётся переписать полностью. Вторая трудность заключается в слиянии изменений из основной ветки проекта и изменений в форке. Так как какие-то куски кода будут переписаны, то, возможно, часть изменений будут непереносимы. Собственно, по этой причине я мог бы посоветовать энтузиастам не бросаться переписывать РосЯму сначала, а написать некий адаптер, который будет эмулировать Битрикс, а на самом деле будет работать с интерфейсом выбранной платформы. Наверняка этот адаптер кому-нибудь ещё пригодится. Я бы с удовольствием оказал посильную помощь в разработке — только позовите.
В модуле РосЯмы описаны классы со статическими функциями, которые обеспечивают абстракцию «ямы» от базы данных практически везде (я так говорю потому что не уверен, что кто-то из нас, разработчиков Гринсайта, смог удержаться от соблазна и не воткнул где-нибудь вызов mysql_query()) — это получение списка ям, добавление, удаление и так далее. Там же лежат функции API. Всё, что касается изменения ямы — апдейт, смена статуса, удаление, и так далее, делается через внутренний вызов API. Так сделано для того, чтоб надо было в одном месте вносить исправления. Реализован внутренний вызов API не очень качественно, а как сраная подпорка покосившегося забора, но так уж сложилось исторически. Описанные в модулях функции вызываются из компонентов. Внутри компонентов полученные данные слегка перевариваются и выгружаются в шаблоны.
Для того, чтоб обеспечить нормальное функционирование модулей, потребуется реализовать как минимум подставные классы объектов $DB (как минимум функции Query, StartTransaction, Rollback, Commit, LastID) и $USER (как минимум функции Login, Logout, IsAdmin, Authorize, GetID, GetByID), заглушку для CModule::IncludeModule() и функцию Fetch объекта, который будет возвращать $DB->Query(). Я говорю «как минимум», потому что не уверен в том, что не придётся делать что-то ещё.
Компоненты более глубоко интегррированы в Битрикс. Компонент профиля пользователя лучше полностью переписать, взяв за основу что-нибудь аналогичное по смыслу из целевой платформы, остальные компоненты — частично, но, по-моему, не очень сильно, а так, местами. Публичная часть не так важна, поэтому можно её переделывать сильнее (новости, f.a.q.), но тут ещё придётся реализовать свой вариант $APPLICATION->IncludeCompoment(). С интеграцией шаблона проблем не возникнет, там всего только хедер, футер, пара скриптов да css, также никаких проблем не должно быть с шаблонами компонентов, надо только не забыть, что Битрикс автоматически подключает файлы script.js и style.css из папки с шаблоном компонента. Ну и админку (редактирование списка ям) придётся переписать полностью, если это вообще надо — администратор может удалять ямы пачками прямо из публичной части.
Тьфу, чуть не забыл. Справочники ФИО начальников ГИБДД и прокуратур по Субъектам РФ хранятся в инфоблоках, значит, надо будет ещё их перенести в другое место хранения, можно в отдельные таблицы, исправить соответствующие места в коде и переделать парсеры, которые должны выбирать соответствующую информацию с сайтов госорганов и обновлять справочники.
Вроде всё, ничего, казалось бы, сверхъестественного, однако, на самом деле это дофига.
А по первому пункту, про Битрикс, я более подробно расскажу. РосЯмы сделана как модуль Битрикса, кроме того, есть ещё росямовские компоненты и шаблон. Более того, РосЯма впаяна и в админку битрикса. Вообщем, она довольно плотно туда интегрирована, и, как я уже говорил, выкорчевать её из Битрикса для того, чтоб перенести на какую-нибудь другую платформу, будет непросто. Но возможно. Любой желающий может сделать битрикс-фри форк проекта и попытаться перенести РосЯму на другую платформу. И столкнуться с несколькими трудностями.
Первая трудность — именно выкорчёвывание. Некоторая часть функционала РосЯмы очень плотно привязана к Битриксу и без него работать не будет, эти части придётся переписать полностью. Вторая трудность заключается в слиянии изменений из основной ветки проекта и изменений в форке. Так как какие-то куски кода будут переписаны, то, возможно, часть изменений будут непереносимы. Собственно, по этой причине я мог бы посоветовать энтузиастам не бросаться переписывать РосЯму сначала, а написать некий адаптер, который будет эмулировать Битрикс, а на самом деле будет работать с интерфейсом выбранной платформы. Наверняка этот адаптер кому-нибудь ещё пригодится. Я бы с удовольствием оказал посильную помощь в разработке — только позовите.
В модуле РосЯмы описаны классы со статическими функциями, которые обеспечивают абстракцию «ямы» от базы данных практически везде (я так говорю потому что не уверен, что кто-то из нас, разработчиков Гринсайта, смог удержаться от соблазна и не воткнул где-нибудь вызов mysql_query()) — это получение списка ям, добавление, удаление и так далее. Там же лежат функции API. Всё, что касается изменения ямы — апдейт, смена статуса, удаление, и так далее, делается через внутренний вызов API. Так сделано для того, чтоб надо было в одном месте вносить исправления. Реализован внутренний вызов API не очень качественно, а как сраная подпорка покосившегося забора, но так уж сложилось исторически. Описанные в модулях функции вызываются из компонентов. Внутри компонентов полученные данные слегка перевариваются и выгружаются в шаблоны.
Для того, чтоб обеспечить нормальное функционирование модулей, потребуется реализовать как минимум подставные классы объектов $DB (как минимум функции Query, StartTransaction, Rollback, Commit, LastID) и $USER (как минимум функции Login, Logout, IsAdmin, Authorize, GetID, GetByID), заглушку для CModule::IncludeModule() и функцию Fetch объекта, который будет возвращать $DB->Query(). Я говорю «как минимум», потому что не уверен в том, что не придётся делать что-то ещё.
Компоненты более глубоко интегррированы в Битрикс. Компонент профиля пользователя лучше полностью переписать, взяв за основу что-нибудь аналогичное по смыслу из целевой платформы, остальные компоненты — частично, но, по-моему, не очень сильно, а так, местами. Публичная часть не так важна, поэтому можно её переделывать сильнее (новости, f.a.q.), но тут ещё придётся реализовать свой вариант $APPLICATION->IncludeCompoment(). С интеграцией шаблона проблем не возникнет, там всего только хедер, футер, пара скриптов да css, также никаких проблем не должно быть с шаблонами компонентов, надо только не забыть, что Битрикс автоматически подключает файлы script.js и style.css из папки с шаблоном компонента. Ну и админку (редактирование списка ям) придётся переписать полностью, если это вообще надо — администратор может удалять ямы пачками прямо из публичной части.
Тьфу, чуть не забыл. Справочники ФИО начальников ГИБДД и прокуратур по Субъектам РФ хранятся в инфоблоках, значит, надо будет ещё их перенести в другое место хранения, можно в отдельные таблицы, исправить соответствующие места в коде и переделать парсеры, которые должны выбирать соответствующую информацию с сайтов госорганов и обновлять справочники.
Вроде всё, ничего, казалось бы, сверхъестественного, однако, на самом деле это дофига.
