#ruby-on-rails #cakephp
#ruby-on-rails #cakephp
Вопрос:
Я разработчик rails, работающий над сайтом cakephp. Чем больше работы они мне присылают, тем больше php-кода я пишу и, следовательно, тем большую зависимость от php мы вводим. Чего я хочу, так это прекратить писать новые функции в php и начать писать их в rails. Наши ресурсы ограничены, а существующий php-сайт огромен, поэтому полный перенос cake на rails невозможен.
Есть ли какой-нибудь способ написать новые функции в приложении rails, сохраняя при этом и предоставляя доступ ко всем функциям старого php (и наоборот)?
Кажется, мне понадобилось бы приложение с поддержкой маршрутизации для передачи запросов либо на php, либо на rails, но затем мы сталкиваемся с проблемой, например, того, что существующая пользовательская функциональность, написанная на php, недоступна для приложения rails и наоборот.
Как насчет чего-нибудь для перевода ruby на php? Таким образом, я мог бы начать писать материал для своей модели на ruby / rails, а не на php.
Я чувствую, что мой вопрос запутан тем фактом, что я не знаю, как задавать вопросы, на которые я хочу ответить, поэтому, надеюсь, это понятно.
Как всегда, заранее спасибо!
Ответ №1:
Один из подходов, который вы можете счесть полезным, заключается в использовании возможностей вашего веб-сервера для правильной перезаписи и делегирования запросов двум разным системам. Если вы можете спроектировать свое новое приложение Rails так, чтобы оно использовало те же записи базы данных, что и старое, с моделями, напрямую сопоставляющимися со старыми таблицами, и гарантирующими, что сеансы, установленные одним, действительны в другом, у вас есть большая свобода действий в том, как вы это делаете.
Apache имеет очень полнофункциональную систему перезаписи URL-адресов и прокси-сервера, которую можно настроить так, чтобы направлять «устаревшие» части вашего сайта на существующий набор PHP-скриптов, направляя весь остальной трафик в новое приложение Rails. Вам нужно быть осторожным, чтобы дизайн обоих приложений был почти идентичным, иначе это может показаться пользователям странным.
Другой подход, который помогает обеспечить согласованный внешний вид, заключается в удалении большей части темы из вашего PHP-приложения. Создавая очень простые страницы, которые предоставляют только необходимую функциональность на каждой странице, Rails может извлекать их, передавая любую соответствующую информацию об аутентификации сеанса, и повторно оформлять их в нужном формате.
Таким образом, вы можете сохранить существующую функциональность и встроить ее в свое новое приложение. Вы можете использовать что-нибудь такое простое, как open-uri
или curb
gem, для обработки этого делегирования на уровне HTTP.
В итоге вы получите контроллеры, которые выглядят следующим образом:
class PaymentController < ApplicationController
def index
@content = fetch_legacy_url('/payments/index.php'))
end
end
fetch_legacy_url
Метод создаст HTTP-запрос на выборку, который включает требуемые заголовки, файлы cookie и так далее, и вернет тело ответа. Затем ваш вид будет выглядеть примерно так:
<%= @content =>
Оттуда вы можете передавать части PHP-макета в приложение Rails по частям. Например, удаление больших кусков статического HTML и помещение их в шаблон Rails уменьшило бы объем фактического PHP-кода, который вам нужно портировать.
Немного запутанно поддерживать два приложения параллельно, но, как вы указали, альтернативой является дальнейшее накопление технического долга и неизбежное переписывание, что является гораздо более значительным мероприятием.
Первым шагом было бы поэкспериментировать и посмотреть, сможете ли вы создать среду Rails, которая использует ваши существующие данные или, по крайней мере, данные, относящиеся к новой функциональности, которую вы собираетесь создать.
Комментарии:
1. Спасибо @tadman. определенно, похоже, что есть несколько серьезных мин, которых следует избегать, и проблемы с обслуживанием, которые могут возникнуть очень быстро, особенно при работе в гибкой команде из нескольких разработчиков. Тем не менее, это имеет смысл и звучит как огромный шаг в правильном направлении, поэтому спасибо за ваш подробный ответ. Это ценится.