Comments 45
В демоверсии шаблон на 1024х600 страшновато выглядит (появляется горизонтальная полоса прокрутки). А вообще по виду довольно неплох. Жалко, Ruby я не знаю, так что врятли смогу использовать :(
В демоверсии шаблон на 1024х600 страшновато выглядит (появляется горизонтальная полоса прокрутки)Да, основной ориентир в демо-версии на ширину экрана минимум 1280px, хотя при ширине 1024px всё не так уж страшно, горизонтальная прокрутка относительно небольшая.
А вообще по виду довольно неплох.Спасибо
Теперь я знаю ruby! Наконец-то нашел замену opencart :)
Да выглядит действительно очень и очень не плохо и вполне многофункционально. Пора учить рельсы видать, все больше и больше хороших проектов на них появляется.
В демо мобильная версия не работает на iPad после первого перехода по ссылке
Spree всегда был той ещё поделкой, и смысла его писать на rails было немного. он ужасно документирован, крайне не гибок, ужасный код, а то, что он написан с помощью Engines усугубляет это ещё дальше. последний мой опыт общения с ним пару месяцев назад закончился тем, что после недели бурного секса пришлось ставить OpenCart.
на самом деле хорошо, что появились люди, которые будут делать сборки-локализации для него, однако я больше ставлю на этот проект. Побольше бы туда людей начало коммитить.
на самом деле хорошо, что появились люди, которые будут делать сборки-локализации для него, однако я больше ставлю на этот проект. Побольше бы туда людей начало коммитить.
попробовал ror-e.com
и код почитал.
это и есть поделка.
и код почитал.
это и есть поделка.
У Вас какая-то личная обида на Spree раз Вы распространяете заведомо ложную информацию?
Для разработчиков есть вполне хорошая документация — spreecommerce.com/documentation/overview
По поводу гибкости, даже интересно, какую это e-commerce задачу нельзя решить при помощи Spree? Сотни магазинов, от groupphotos.com до stickermule.com как бы прозрачно намекают, что возможности кастомизации в Spree практически ничем не ограничены.
Код Spree может и не идеальный, но на уровне лучших представителей OpenSource движков. Если есть сказать что-то конкретное на этот счёт, то прошу продемонстрировать в виде pull request'а, а не голословных обвинений.
ror-e — это шоу одного человека, которому самому уже надоело развивать проект, если у вас есть желание впадать в жёсткую зависимость от его настроения или продолжать его проект самому, то вперёд. Свободу выбора никто не отменял.
Для разработчиков есть вполне хорошая документация — spreecommerce.com/documentation/overview
По поводу гибкости, даже интересно, какую это e-commerce задачу нельзя решить при помощи Spree? Сотни магазинов, от groupphotos.com до stickermule.com как бы прозрачно намекают, что возможности кастомизации в Spree практически ничем не ограничены.
Код Spree может и не идеальный, но на уровне лучших представителей OpenSource движков. Если есть сказать что-то конкретное на этот счёт, то прошу продемонстрировать в виде pull request'а, а не голословных обвинений.
однако я больше ставлю на ror-e.com проект. Побольше бы туда людей начало коммитить.Вы серьёзно? :-)
ror-e — это шоу одного человека, которому самому уже надоело развивать проект, если у вас есть желание впадать в жёсткую зависимость от его настроения или продолжать его проект самому, то вперёд. Свободу выбора никто не отменял.
> разработчиков есть вполне хорошая документация
на момент двух месяцев назад документация была хороша и описывала всё вплоть до последнего пука, но только для пользователей, а не для разработчиков. вы явно не пытались писать с нуля модуль или шаблон к Spree.
> Сотни магазинов, от groupphotos.com до stickermule.com как бы прозрачно намекают, что возможности кастомизации в Spree практически ничем не ограничены
Я понимаю, что после OpenCart'ов и E-Commerce'ов может так казаться. но только вглядитесь в них всех. да там даже layout'ы никак не сменены. максимум изменений дизайнов у всех — вставлена пара hook'ов, да css подправлен.
> Код Spree может и не идеальный, но на уровне лучших представителей OpenSource движков
Вы серьёзно? :-) (с) да вы туда хоть смотрели? нет, никаких пулл-реквестов. я к этому прикасаться больше не буду.
по части ror-e повторюсь: я не говорю, что им уже пользоваться можно. но он строится на более разумных основах и более rails-way.
а этот ваш Spree хорош не более, чем тысячи PHP CMS (по крайней мере я не могу придумать ни одного аргумента, почему мне надо использовать Spree, а не E-Commerce или OpenCart). Только он на rails написан, и от него ожидаешь большего. а он ожиданиям не соответствует.
на момент двух месяцев назад документация была хороша и описывала всё вплоть до последнего пука, но только для пользователей, а не для разработчиков. вы явно не пытались писать с нуля модуль или шаблон к Spree.
> Сотни магазинов, от groupphotos.com до stickermule.com как бы прозрачно намекают, что возможности кастомизации в Spree практически ничем не ограничены
Я понимаю, что после OpenCart'ов и E-Commerce'ов может так казаться. но только вглядитесь в них всех. да там даже layout'ы никак не сменены. максимум изменений дизайнов у всех — вставлена пара hook'ов, да css подправлен.
> Код Spree может и не идеальный, но на уровне лучших представителей OpenSource движков
Вы серьёзно? :-) (с) да вы туда хоть смотрели? нет, никаких пулл-реквестов. я к этому прикасаться больше не буду.
по части ror-e повторюсь: я не говорю, что им уже пользоваться можно. но он строится на более разумных основах и более rails-way.
а этот ваш Spree хорош не более, чем тысячи PHP CMS (по крайней мере я не могу придумать ни одного аргумента, почему мне надо использовать Spree, а не E-Commerce или OpenCart). Только он на rails написан, и от него ожидаешь большего. а он ожиданиям не соответствует.
вместо E-Commerce имелся в виду OS-Commerce
вы явно не пытались писать с нуля модуль или шаблон к SpreeДа я уж со счёта сбился сколько я расширений(модулей) для Spree написал с нуля… Хотя спорить насчёт качества документации я не хочу, я хочу лишь добиться более конструктивных замечаний, чтобы лучше понимать какие темы недостаточно освещены. А от Вашей нигилистической позиции никому лучше не станет.
но только вглядитесь в них всех. да там даже layout'ы никак не сменены. максимум изменений дизайнов у всех — вставлена пара hook'ов, да css подправлен.Я, честно говоря, имел в виду функциональные изменения, а не внешние. Что касается дизайна, я лично не дизайнер, поэтому даже вглядываться не буду. Внедрить Synergy/Spree можно в любой e-commerce дизайн.
какие темы не освещены? проблема в том, что я в коде Spree копался довольно долго, и модули к нему писал, потому точно не скажу, какие темы не освещены.
первое, что приходит в голову — создание своего шаблона. всё, что освещено в доках — это хуки, которые мне лично сразу не понравились. решение в стиле «прощай ООП».
ещё было бы интересно посмотреть на пример импорта данных. я видел документацию на сайте, и видел пару модулей на эту тему, но они изрядно лагали, а примеры по документации были нежизнеспособны. помню, что на этом изрядно натрахался.
первое, что приходит в голову — создание своего шаблона. всё, что освещено в доках — это хуки, которые мне лично сразу не понравились. решение в стиле «прощай ООП».
ещё было бы интересно посмотреть на пример импорта данных. я видел документацию на сайте, и видел пару модулей на эту тему, но они изрядно лагали, а примеры по документации были нежизнеспособны. помню, что на этом изрядно натрахался.
по части «вы явно не пытались писать с нуля модуль или шаблон к Spree» перефразирую — не пытались этого делать по документации.
Ну, лично для меня лучшая документация — это код.
Хотя вот сейчас специально перечитал Spree Extension Tutorial, Customization Overview и бегло просмотрел другие статьи из раздела «Digging Deeper» и даже сходу не могу сказать что там не описано. Наверняка какие-нибудь тонкости остались незадокументированными. Но то, что прочитав всю эту документацию, невозможно создать расширение с нуля — это, мягко говоря, не правда. Сложность такой задачи зависит скорее от сложности самого расширения, а документации по сопряжению своего кода со Spree вполне достаточно для разработки собственных расширений, при условии что разработчик знаком с Ruby on Rails. И к чести авторов документации замечу, что сейчас она гораздо лучше отражает реалии текущей версии Spree, чем это было, к примеру, 1.5 года назад.
Хотя вот сейчас специально перечитал Spree Extension Tutorial, Customization Overview и бегло просмотрел другие статьи из раздела «Digging Deeper» и даже сходу не могу сказать что там не описано. Наверняка какие-нибудь тонкости остались незадокументированными. Но то, что прочитав всю эту документацию, невозможно создать расширение с нуля — это, мягко говоря, не правда. Сложность такой задачи зависит скорее от сложности самого расширения, а документации по сопряжению своего кода со Spree вполне достаточно для разработки собственных расширений, при условии что разработчик знаком с Ruby on Rails. И к чести авторов документации замечу, что сейчас она гораздо лучше отражает реалии текущей версии Spree, чем это было, к примеру, 1.5 года назад.
первое, что приходит в голову — создание своего шаблона. всё, что освещено в доках — это хуки, которые мне лично сразу не понравилисьА это разве не то:
spreecommerce.com/documentation/customization.html#template-replacements
To override any of Spree’s default views, including those for the admin interface, simply create a file with the same filename in your app/views directory.
For example, to override the main layout, create the file YOUR_SITE_OR_EXTENSION/app/views/layouts/spree_application.html.erb
Что касается создания новых вьюх, то оно ничем не отличается от любого Rails-приложения, простое добавление файла в app/views/**
Что касается хуков, то они существуют для облегчения обновления и интеграции с расширениями. Кстати, хуки будут вскоре заменены на ещё более гибкое решение — github.com/BDQ/deface
To override any of Spree’s default views, including those for the admin interface, simply create a file with the same filename in your app/views directory.
For example, to override the main layout, create the file YOUR_SITE_OR_EXTENSION/app/views/layouts/spree_application.html.erb
и это вся документация по созданию шаблонов. то, что надо переопределить файл — это понятно почти всем. главная проблема — это то, что т.к. CMS основан на engines,
а) за оригиналом файла надо лезть в гем или на гитхаб
б) из API ничего не понятно
в) надо разбираться в коде CMS чтобы сверстать шаблон (!)
могу сразу сказать, что главная вещь, почему мне не понравились хуки — это потому, что даже partials намного удобнее.
1) Spree — это не совсем CMS, т.к. она в плане модификаций ориентирована больше на программистов и сделана так, чтобы было удобно именно программистам, а не верстальщикам.
2) partials они может и удобнее, когда надо сделать один магазин с фиксированным функционалом, а вот когда надо сделать хотя бы 10 магазинов с разным функционалом, который ещё и развивается со временем, то partials уже ничем не помогут, в отличии от хуков и deface.
> за оригиналом файла надо лезть в гем или на гитхаб
и это совсем не так сложно, как Вы пытаетесь представить…
> из API ничего не понятно
мне вот из этого замечания тоже ничего не понятно, e-commerce движок — это же не библиотека, чтобы использовать его для разработки нестандартных магазинов, не заглядывая в код.
> надо разбираться в коде CMS чтобы сверстать шаблон (!)
Чтобы сверстать шаблон надо разбираться только в HTML и CSS, а уж внедрять его разумеется будет человек, знакомый с кодом системы.
2) partials они может и удобнее, когда надо сделать один магазин с фиксированным функционалом, а вот когда надо сделать хотя бы 10 магазинов с разным функционалом, который ещё и развивается со временем, то partials уже ничем не помогут, в отличии от хуков и deface.
> за оригиналом файла надо лезть в гем или на гитхаб
и это совсем не так сложно, как Вы пытаетесь представить…
> из API ничего не понятно
мне вот из этого замечания тоже ничего не понятно, e-commerce движок — это же не библиотека, чтобы использовать его для разработки нестандартных магазинов, не заглядывая в код.
> надо разбираться в коде CMS чтобы сверстать шаблон (!)
Чтобы сверстать шаблон надо разбираться только в HTML и CSS, а уж внедрять его разумеется будет человек, знакомый с кодом системы.
> Spree — это не совсем CMS, т.к. она в плане модификаций ориентирована больше на программистов и сделана так, чтобы было удобно именно программистам, а не верстальщикам
Сделана для программистов — Rails. А CMS по определению сделана для тех, кто не хочет париться с кодом.
> то partials уже ничем не помогут, в отличии от хуков и deface
в упор не пойму, почему. чем partials в поддержке хуже хуков и deface?
> и это совсем не так сложно, как Вы пытаетесь представить…
когда вы хотите подправить 1 файл. когда вам нужно править половину вьюх CMS и несколько модулей — можно замордоваться. Особенно, когда это ещё и под разные версии CMS приходится делать.
> e-commerce движок — это же не библиотека
я уже около 3х лет работаю на Rails, и ни разу не смотрел в его код. видимо, просто зажрался.
> Чтобы сверстать шаблон надо разбираться только в HTML и CSS, а уж внедрять его разумеется будет человек, знакомый с кодом системы.
В идеальном мире
Сделана для программистов — Rails. А CMS по определению сделана для тех, кто не хочет париться с кодом.
> то partials уже ничем не помогут, в отличии от хуков и deface
в упор не пойму, почему. чем partials в поддержке хуже хуков и deface?
> и это совсем не так сложно, как Вы пытаетесь представить…
когда вы хотите подправить 1 файл. когда вам нужно править половину вьюх CMS и несколько модулей — можно замордоваться. Особенно, когда это ещё и под разные версии CMS приходится делать.
> e-commerce движок — это же не библиотека
я уже около 3х лет работаю на Rails, и ни разу не смотрел в его код. видимо, просто зажрался.
> Чтобы сверстать шаблон надо разбираться только в HTML и CSS, а уж внедрять его разумеется будет человек, знакомый с кодом системы.
В идеальном мире
> А CMS по определению сделана для тех, кто не хочет париться с кодом.
Ну я ж сказал, что называть Spree CMS — это не совсем верно. А CMS в вашем понимании(сделать что угодно не заглядывая в код системы) на RoR вообще не существует, насколько мне известно.
> в упор не пойму, почему. чем partials в поддержке хуже хуков и deface?
Самый простейший пример — нескольким расширениям нужно вставить определённый partial на определённое место в уже существующем шаблоне. Если бы это делалось через partial в существующем шаблоне, то возник бы конфликт расширений.
Ну я ж сказал, что называть Spree CMS — это не совсем верно. А CMS в вашем понимании(сделать что угодно не заглядывая в код системы) на RoR вообще не существует, насколько мне известно.
> в упор не пойму, почему. чем partials в поддержке хуже хуков и deface?
Самый простейший пример — нескольким расширениям нужно вставить определённый partial на определённое место в уже существующем шаблоне. Если бы это делалось через partial в существующем шаблоне, то возник бы конфликт расширений.
на мой взгляд прекрасная система/сборка но не хватает инфраструктуры, надеюсь что она станет так же популярна как ecommmerce на php
Интересно, нужно поковырять, тем более на рельсах.
Когда дело касается php я лично выбираю ModX + shopkeeper и безумно доволен, вообще модх'сом доволен.
Когда дело касается php я лично выбираю ModX + shopkeeper и безумно доволен, вообще модх'сом доволен.
Однозначно, я бы не стал этим пользоваться. Этому движку явно требуется оптимизация работы. Хотя возможно сервер где лежит демка, стоит 2.99$ за год и поэтому страницы так долго генерируются. Но если это не так, то пациент требует лечения.
Демка лежит на обычном shared-хостинге, который стоит скорее 29.9$ за год. По данным анализа логов, среднее время отдачи для самых нагруженных страниц следующее:
Если у Вас было сильно хуже, то возможно Вы попали на момент, когда кто-нибудь решил провести нагрузочное тестирование демки, для чего shared-хостинг конечно слабо предназначен.
- главная страница — 0.14s
- страница категории — 0.24s
- страница товара — 0.28s
Если у Вас было сильно хуже, то возможно Вы попали на момент, когда кто-нибудь решил провести нагрузочное тестирование демки, для чего shared-хостинг конечно слабо предназначен.
У комментариев ников не видно :) и при доб-е товара ошибка) ngix выходит — возможно хабраэффект)
> У комментариев ников не видно :)
Они просто пустые в демо-данных :-)
Заапрувил несколько свежих комментариев с никами, например здесь: demo.synergycommerce.ru/products/apple-iphone-4-32gb
> и при доб-е товара ошибка) ngix выходит — возможно хабраэффект)
Возможно, воспроизвести не удалось… будем разбираться.
Они просто пустые в демо-данных :-)
Заапрувил несколько свежих комментариев с никами, например здесь: demo.synergycommerce.ru/products/apple-iphone-4-32gb
> и при доб-е товара ошибка) ngix выходит — возможно хабраэффект)
Возможно, воспроизвести не удалось… будем разбираться.
Уф. Наконец то наши взялись за эту «попойку» ))) Успехов!
Извиняюсь, если туплю — а где демка админки?
Демки админки пока нет в свободном доступе, планируется сделать её публичной через 2-3 недели. Выглядит она примерно так: habreffect.ru/34e/d57bb3afc
Накладные генермровать умеет?
synergy on spree on rails on ruby
Для программистов наверно звучит как песня.
В описании spree написано что решение ориентировано на серьезные организации, которым не влом содержать 2-3 программистов.
Для программистов наверно звучит как песня.
В описании spree написано что решение ориентировано на серьезные организации, которым не влом содержать 2-3 программистов.
> synergy on spree on rails on ruby
Да, звучит прикольно, только Synergy не повышает уровень абстракции, так что скорее Synergy Spree on Rails on Ruby
> В описании spree написано что решение ориентировано на серьезные организации, которым не влом содержать 2-3 программистов.
Так и есть, но наличие готовой сборки в виде Synergy уже сокращает это требование до 1 программиста для большинства случаев. :)
Кроме того, делать всё самостоятельно и содержать в штате программистов ведь совсем не обязательно, можно просто сотрудничать с фирмой, оказывающей соответствующие услуги…
Да, звучит прикольно, только Synergy не повышает уровень абстракции, так что скорее Synergy Spree on Rails on Ruby
> В описании spree написано что решение ориентировано на серьезные организации, которым не влом содержать 2-3 программистов.
Так и есть, но наличие готовой сборки в виде Synergy уже сокращает это требование до 1 программиста для большинства случаев. :)
Кроме того, делать всё самостоятельно и содержать в штате программистов ведь совсем не обязательно, можно просто сотрудничать с фирмой, оказывающей соответствующие услуги…
Есть ли возможность продавать уникальные цифровые товары (например, лицензионные коды к играм или PIN-коды)?
«Поддержка всех основных способов оплаты через сервис «Робокасса» „
Для визы только робокасса? Они берут 5%. Еще же есть куча гейтов, типа киберплата и насколько знаю это рбк или как их там сейчас называют. Опять таки ассист (хотя это для оборотистых магазинов).
Есть решения например для: Дизайнер хочет продавать свои дизайнерские тарелки, а оплату получать исключительно через визу
Для визы только робокасса? Они берут 5%. Еще же есть куча гейтов, типа киберплата и насколько знаю это рбк или как их там сейчас называют. Опять таки ассист (хотя это для оборотистых магазинов).
Есть решения например для: Дизайнер хочет продавать свои дизайнерские тарелки, а оплату получать исключительно через визу
Как у нее с интеграцией с 1С?
На первый взгляд выглядит хорошо.
Но с точки зрения покупателя нехватает фильтра/сортировки товаров (например отсортировать моб. телефоны по каким-то характеристикам.)
А с точки зрения админа — важно, чтобы была возможность импорта excel-файлов с перечнем товаров, как это сделано отдельным модулем в opencart.
Но с точки зрения покупателя нехватает фильтра/сортировки товаров (например отсортировать моб. телефоны по каким-то характеристикам.)
А с точки зрения админа — важно, чтобы была возможность импорта excel-файлов с перечнем товаров, как это сделано отдельным модулем в opencart.
Фильтры можно сделать через Solr, в базовую версию они не входят.
> важно, чтобы была возможность импорта excel-файлов с перечнем товаров, как это сделано отдельным модулем в opencart
Ну импорт — штука индивидуальная, пока разработка универсальных решений для импорта из Excel не планируется. А под конкретный случай написать не сложно.
> важно, чтобы была возможность импорта excel-файлов с перечнем товаров, как это сделано отдельным модулем в opencart
Ну импорт — штука индивидуальная, пока разработка универсальных решений для импорта из Excel не планируется. А под конкретный случай написать не сложно.
Не могу удержатся чтобы не добавить в копилку противостояния Source и GearHead :)
Я работаю в одном офисе с Девидом, и поверьте настроения у него хватит не на один такой проект, так что он будет развиваться и далее. Безусловно ror-e сыроват, однако по мне, работая непосредственно с наследием Spree (которое кстати было нещадно вырублено из приложения чтобы оставить нормальный Rails app) и периодически просматривающий код ror-e могу сказать что у ror-e вполне нормальное будущее, избавленное от маразмов существующих в Spree годами. Проектом интересуются и рано или поздно туда будет коммитить больше людей и развитие пойдет быстрее и в более качественном направлении.
Не хочу влазить в бесконечный спор spree vs. whatever ибо это бесполезно, однако из личного опыта могу сказать что архитектура spree не потянет двухмиллионную базу постоянных пользователей (300-400 тысяч посещений в день). Spree хорош для маленьких магазинчиков — натянул свой шаблон и готово, продавай себе по десятку товаров в день и бед знать не будешь. Из-за своей мега-гибкости (которая кстати сомнительная, что может быть гибче Ruby и Rails для хорошего программиста ;)), они серьезно просчитались с перфомансом. А вот ror-e в этом плане подает надежды, ибо его разработчик набил немало шишек на Spree.
Я работаю в одном офисе с Девидом, и поверьте настроения у него хватит не на один такой проект, так что он будет развиваться и далее. Безусловно ror-e сыроват, однако по мне, работая непосредственно с наследием Spree (которое кстати было нещадно вырублено из приложения чтобы оставить нормальный Rails app) и периодически просматривающий код ror-e могу сказать что у ror-e вполне нормальное будущее, избавленное от маразмов существующих в Spree годами. Проектом интересуются и рано или поздно туда будет коммитить больше людей и развитие пойдет быстрее и в более качественном направлении.
Не хочу влазить в бесконечный спор spree vs. whatever ибо это бесполезно, однако из личного опыта могу сказать что архитектура spree не потянет двухмиллионную базу постоянных пользователей (300-400 тысяч посещений в день). Spree хорош для маленьких магазинчиков — натянул свой шаблон и готово, продавай себе по десятку товаров в день и бед знать не будешь. Из-за своей мега-гибкости (которая кстати сомнительная, что может быть гибче Ruby и Rails для хорошего программиста ;)), они серьезно просчитались с перфомансом. А вот ror-e в этом плане подает надежды, ибо его разработчик набил немало шишек на Spree.
Я работаю в одном офисе с Девидом, и поверьте настроения у него хватит не на один такой проект, так что он будет развиваться и далее.Не верю, может у него и хватит настроения сделать со временем что-то близкое к production-ready. Но существует множество примеров, как проекты гораздо более качественные, чем ror-e, загибались когда единственный коммитер терял к ним интерес, взять тот же searchlogic или resource_controller.
могу сказать что у ror-e вполне нормальное будущее, избавленное от маразмов существующих в Spree годамиСудя по всему, этот оборот основан исключительно на высосанных из пальца выпадах Дэвида в сторону Spree, которые по большей части не имеют ничего общего с действительностью.
из личного опыта могу сказать что архитектура spree не потянет двухмиллионную базу постоянных пользователей (300-400 тысяч посещений в день)Да бросьте Вы пугру гнать, при такой нагрузке всё будет обвешано кешированием в любом случае, причём настолько, что для быстродействия уже будет не важно какая там архитектура. Архитектура будет иметь влияние только на сроки разработки и тут Spree легко обойдёт ror-e и уж тем более написание всего на чистом Rails.
Spree хорош для маленьких магазинчиков — натянул свой шаблон и готово, продавай себе по десятку товаров в день и бед знать не будешь.И тем не менее демо-версия на shared-хостинге вполне спокойно выдержала более 17000 просмотров страниц за день! Если перенести на какой-нибудь средненький VDS с 1Gb RAM, то будет выдерживать и 50000 просмотров в день постоянно. Всем бы маленьким магазинчикам такую посещаемость! :-D
Sign up to leave a comment.
Synergy — платформа для создания интернет-магазинов