Итак, мы хотим перестроить часть нашего сайта как приложение Rails.Первоначально планировалось создать основное приложение «site» с несколькими подключаемыми приложениями (Rails 3.1 Engines) с разделенной функциональностью - компонентом магазина, компонентом для общения / форумов / чата и т. Д. Кроме того, мы хотели разместить темы/ стилизация под самоцвет, чтобы наши веб-дизайнеры могли изменять внешний вид сайта и некоторые незначительные изменения макета без необходимости «знать Rails».Первоначально все шло хорошо;мы создали основную архитектуру, плагины и жемчужину темы, и все это прекрасно сочеталось;сквозная функциональность, такая как auth, была добавлена в основное приложение «site» и использовалась приложениями плагинов, что дало нам единый вход на сайт (требование дизайна).
Наш первоначальный план дляКомпонент store должен был использовать Spree (http://spreecommerce.com/), поскольку в нем было 95% дополнительных функциональных возможностей, которые нам были необходимы. Однако есть одна загвоздка - Spree распространяется как монтируемый движок, но также является приложением.Это означает, что Spree монтируется не только внутри приложения (что не является проблемой, на самом деле это поведение, на которое мы рассчитывали), но оно зависит от контроля над основным приложением .«для этого поведения, по-видимому, он зависит от двух основных частей функциональности. Первая часть функциональности - это некоторая функциональность перезаписи постоянных ссылок SEO, которая должна перейти в промежуточное ПО; мы могли бы взломать вещи так, чтобы наше основное приложение включало этот кусок кода (дажехотя это начало бы запутывать функциональность магазина по всему нашему сайту, запутываяntable engine "история ... подробнее об этом чуть позже).
Более сложным является то, что Spree использует Deface для создания тем и настройки.Хотя это «умно» (обратите внимание на цитаты), это действительно делает интеграцию Spree своего рода кошмаром;либо вы идете по пути наименьшего сопротивления и делаете Spree целым магазином для себя (что полностью нарушает нашу историю о том, что магазин - это только одна часть нашего сайта, и он хорошо сочетается с остальной частью сайта, включая аутентификацию, тематику и т. д.. "), или вам придется взломать Spree.
Мало того, что Spree не следует стандартной парадигме маршрутизации Rails Engine, где маршруты изолированы ниже корня движка (если вы посмотритев файле lib.ways вы можете увидеть, что она использует Rails.Application вместо маршрутов Engine).Это означает, что у нас не может быть www.oursite.com/store/...all_the_spree_goodness, нам нужно иметь www.oursite.com/spree_owns_the_sites_routes ...
Итак, кто-нибудь еще пробовал это?Мы любим веселье и хотели бы использовать его в качестве нашего магазина.Но начинает казаться, что нет никакого реального способа «интегрировать» его с остальной частью нашего сайта, за исключением, возможно, некоторой проксирующей магии с nginx или чем-то в этом роде (что является отдельным кошмаром, так как мы надеемся разместить на Heroku,а затем мы должны выяснить, как интегрировать несколько разрозненных приложений в одну БД - для единой авторизации входа - и передний маршрутизатор HTTP).
Разработчики Spree, мы ЛЮБИМ ваш код, но естькакая работа делается для того, чтобы превратить его в актуальный, по-настоящему Rails Engine, в отличие от автономного приложения, которое просто упаковывает все свои функции в движки?Без возможности интегрировать его в существующий сайт (в том числе не «владеть» приложением, иметь возможность разделять все его маршрутов и т. Д.) Просто невозможно использовать его:(
TIA.