Фильтры можно сделать через Solr, в базовую версию они не входят.
> важно, чтобы была возможность импорта excel-файлов с перечнем товаров, как это сделано отдельным модулем в opencart
Ну импорт — штука индивидуальная, пока разработка универсальных решений для импорта из Excel не планируется. А под конкретный случай написать не сложно.
Да, звучит прикольно, только Synergy не повышает уровень абстракции, так что скорее Synergy Spree on Rails on Ruby
> В описании spree написано что решение ориентировано на серьезные организации, которым не влом содержать 2-3 программистов.
Так и есть, но наличие готовой сборки в виде Synergy уже сокращает это требование до 1 программиста для большинства случаев. :)
Кроме того, делать всё самостоятельно и содержать в штате программистов ведь совсем не обязательно, можно просто сотрудничать с фирмой, оказывающей соответствующие услуги…
> А CMS по определению сделана для тех, кто не хочет париться с кодом.
Ну я ж сказал, что называть Spree CMS — это не совсем верно. А CMS в вашем понимании(сделать что угодно не заглядывая в код системы) на RoR вообще не существует, насколько мне известно.
> в упор не пойму, почему. чем partials в поддержке хуже хуков и deface?
Самый простейший пример — нескольким расширениям нужно вставить определённый partial на определённое место в уже существующем шаблоне. Если бы это делалось через partial в существующем шаблоне, то возник бы конфликт расширений.
1) Spree — это не совсем CMS, т.к. она в плане модификаций ориентирована больше на программистов и сделана так, чтобы было удобно именно программистам, а не верстальщикам.
2) partials они может и удобнее, когда надо сделать один магазин с фиксированным функционалом, а вот когда надо сделать хотя бы 10 магазинов с разным функционалом, который ещё и развивается со временем, то partials уже ничем не помогут, в отличии от хуков и deface.
> за оригиналом файла надо лезть в гем или на гитхаб
и это совсем не так сложно, как Вы пытаетесь представить…
> из API ничего не понятно
мне вот из этого замечания тоже ничего не понятно, e-commerce движок — это же не библиотека, чтобы использовать его для разработки нестандартных магазинов, не заглядывая в код.
> надо разбираться в коде CMS чтобы сверстать шаблон (!)
Чтобы сверстать шаблон надо разбираться только в HTML и CSS, а уж внедрять его разумеется будет человек, знакомый с кодом системы.
Ну, лично для меня лучшая документация — это код.
Хотя вот сейчас специально перечитал Spree Extension Tutorial, Customization Overview и бегло просмотрел другие статьи из раздела «Digging Deeper» и даже сходу не могу сказать что там не описано. Наверняка какие-нибудь тонкости остались незадокументированными. Но то, что прочитав всю эту документацию, невозможно создать расширение с нуля — это, мягко говоря, не правда. Сложность такой задачи зависит скорее от сложности самого расширения, а документации по сопряжению своего кода со Spree вполне достаточно для разработки собственных расширений, при условии что разработчик знаком с Ruby on Rails. И к чести авторов документации замечу, что сейчас она гораздо лучше отражает реалии текущей версии Spree, чем это было, к примеру, 1.5 года назад.
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
вы явно не пытались писать с нуля модуль или шаблон к Spree
Да я уж со счёта сбился сколько я расширений(модулей) для Spree написал с нуля… Хотя спорить насчёт качества документации я не хочу, я хочу лишь добиться более конструктивных замечаний, чтобы лучше понимать какие темы недостаточно освещены. А от Вашей нигилистической позиции никому лучше не станет.
но только вглядитесь в них всех. да там даже layout'ы никак не сменены. максимум изменений дизайнов у всех — вставлена пара hook'ов, да css подправлен.
Я, честно говоря, имел в виду функциональные изменения, а не внешние. Что касается дизайна, я лично не дизайнер, поэтому даже вглядываться не буду. Внедрить Synergy/Spree можно в любой e-commerce дизайн.
Демка лежит на обычном shared-хостинге, который стоит скорее 29.9$ за год. По данным анализа логов, среднее время отдачи для самых нагруженных страниц следующее:
главная страница — 0.14s
страница категории — 0.24s
страница товара — 0.28s
Если у Вас было сильно хуже, то возможно Вы попали на момент, когда кто-нибудь решил провести нагрузочное тестирование демки, для чего shared-хостинг конечно слабо предназначен.
У Вас какая-то личная обида на Spree раз Вы распространяете заведомо ложную информацию?
Для разработчиков есть вполне хорошая документация — spreecommerce.com/documentation/overview
По поводу гибкости, даже интересно, какую это e-commerce задачу нельзя решить при помощи Spree? Сотни магазинов, от groupphotos.com до stickermule.com как бы прозрачно намекают, что возможности кастомизации в Spree практически ничем не ограничены.
Код Spree может и не идеальный, но на уровне лучших представителей OpenSource движков. Если есть сказать что-то конкретное на этот счёт, то прошу продемонстрировать в виде pull request'а, а не голословных обвинений.
однако я больше ставлю на ror-e.com проект. Побольше бы туда людей начало коммитить.
Вы серьёзно? :-)
ror-e — это шоу одного человека, которому самому уже надоело развивать проект, если у вас есть желание впадать в жёсткую зависимость от его настроения или продолжать его проект самому, то вперёд. Свободу выбора никто не отменял.
В демоверсии шаблон на 1024х600 страшновато выглядит (появляется горизонтальная полоса прокрутки)
Да, основной ориентир в демо-версии на ширину экрана минимум 1280px, хотя при ширине 1024px всё не так уж страшно, горизонтальная прокрутка относительно небольшая.
Литературы море, качественной — капли.
И эти капли в подавляющем большинстве на английском. При этом некоторые издательства умудряются нанимать для перевода людей, которые из качественной книги способны сделать белиберду.
Кроме того многие хорошие книги ждут хоть какого-то перевода по 5-10 лет
Вы уж извините, но писать программы транслитом — это и есть уровень быдлокодерства. К тому же что Вы будете делать с тысячами библиотек, которые уже имеют стандартный англоязычный API?
а если и пишут на самом английском — особых знаний там не надо, существительные, прилагательные да глаголы в неопределённой степени по 200-300 слов из каждый группы
Ну так и отлично, добавить сюда ещё сотню наречий, немного предлогов, числительных и прочих частей речи и уже получается базовый технический английский, достаточный для чтения документации, с редким заглядыванием в google translate. Этот уровень в любом случае необходим всем, кто хочет делать в IT нечто большее, чем лабораторные работы по информатике, и его вполне достаточно чтобы особо не запариваться отсутствием русскоязычных материалов.
Вы знаете, что запрещено торговать товарами, содержание и способ применения которых не переведён на русский хотя бы на наклейке поверх упаковки?
Вы всерьёз считаете, что языки программирования, библиотеки и фреймворки являются товаром?
Да их практически никто уже не продаёт, 75% популярных технологий — OpenSource, а ещё 15% — Freeware. Платное — узкоспециализированные языки и навороченные библиотеки под некоторые платформы, не будем тыкать пальцем. Суть в том, что студентам и тем более школьникам, ничего (кроме компьютера) покупать не нужно, чтобы изучать программирование.
Подозреваю, что корректным ответом будет: его целевая аудитория знает английский на достаточном для пользования сайтом уровне.
Ну практически так. Русскоязычному сегменту его целевой аудитории гораздо важнее, чтобы движок продолжал отлично поддерживать морфологию русского языка и т.п., чем документация или сайт на русском.
«Всегда прав разработчик технологии» — это недоступный понимаю тезис. Зачем мы с Вами пытаемся выяснить кто прав?
Это не тезис, это аксиома, т.к. практически любая лицензия содержит пункт «AS IS», т.е. если Вам что-то не нравится, Вы не имеете никакого права требовать что-либо от разработчика.
Я же имел в виду, что для улучшения дел в российском IT, нужно создавать в России больше конкурентноспособных технологий, а не переводить документацию. Вот Вы знаете хотя бы 10 российских компаний, которые всерьёз спонсируют работу русских разработчиков OpenSource технологий? Я лично не знаю и вижу в этом гораздо большую проблему, чем в недостатке русскоязычных курсов по программированию.
> важно, чтобы была возможность импорта excel-файлов с перечнем товаров, как это сделано отдельным модулем в opencart
Ну импорт — штука индивидуальная, пока разработка универсальных решений для импорта из Excel не планируется. А под конкретный случай написать не сложно.
Есть поддержка следующих гейтов для оплаты через визу: AuthorizeNet, Beanstream, Braintree, eWAY, LinkPoint, SagePay.
Да, звучит прикольно, только Synergy не повышает уровень абстракции, так что скорее Synergy Spree on Rails on Ruby
> В описании spree написано что решение ориентировано на серьезные организации, которым не влом содержать 2-3 программистов.
Так и есть, но наличие готовой сборки в виде Synergy уже сокращает это требование до 1 программиста для большинства случаев. :)
Кроме того, делать всё самостоятельно и содержать в штате программистов ведь совсем не обязательно, можно просто сотрудничать с фирмой, оказывающей соответствующие услуги…
Ну я ж сказал, что называть Spree CMS — это не совсем верно. А CMS в вашем понимании(сделать что угодно не заглядывая в код системы) на RoR вообще не существует, насколько мне известно.
> в упор не пойму, почему. чем partials в поддержке хуже хуков и deface?
Самый простейший пример — нескольким расширениям нужно вставить определённый partial на определённое место в уже существующем шаблоне. Если бы это делалось через partial в существующем шаблоне, то возник бы конфликт расширений.
2) partials они может и удобнее, когда надо сделать один магазин с фиксированным функционалом, а вот когда надо сделать хотя бы 10 магазинов с разным функционалом, который ещё и развивается со временем, то partials уже ничем не помогут, в отличии от хуков и deface.
> за оригиналом файла надо лезть в гем или на гитхаб
и это совсем не так сложно, как Вы пытаетесь представить…
> из API ничего не понятно
мне вот из этого замечания тоже ничего не понятно, e-commerce движок — это же не библиотека, чтобы использовать его для разработки нестандартных магазинов, не заглядывая в код.
> надо разбираться в коде CMS чтобы сверстать шаблон (!)
Чтобы сверстать шаблон надо разбираться только в HTML и CSS, а уж внедрять его разумеется будет человек, знакомый с кодом системы.
Хотя вот сейчас специально перечитал Spree Extension Tutorial, Customization Overview и бегло просмотрел другие статьи из раздела «Digging Deeper» и даже сходу не могу сказать что там не описано. Наверняка какие-нибудь тонкости остались незадокументированными. Но то, что прочитав всю эту документацию, невозможно создать расширение с нуля — это, мягко говоря, не правда. Сложность такой задачи зависит скорее от сложности самого расширения, а документации по сопряжению своего кода со Spree вполне достаточно для разработки собственных расширений, при условии что разработчик знаком с Ruby on Rails. И к чести авторов документации замечу, что сейчас она гораздо лучше отражает реалии текущей версии Spree, чем это было, к примеру, 1.5 года назад.
spreecommerce.com/documentation/customization.html#template-replacements
Что касается создания новых вьюх, то оно ничем не отличается от любого Rails-приложения, простое добавление файла в app/views/**
Что касается хуков, то они существуют для облегчения обновления и интеграции с расширениями. Кстати, хуки будут вскоре заменены на ещё более гибкое решение — github.com/BDQ/deface
Они просто пустые в демо-данных :-)
Заапрувил несколько свежих комментариев с никами, например здесь: demo.synergycommerce.ru/products/apple-iphone-4-32gb
> и при доб-е товара ошибка) ngix выходит — возможно хабраэффект)
Возможно, воспроизвести не удалось… будем разбираться.
Я, честно говоря, имел в виду функциональные изменения, а не внешние. Что касается дизайна, я лично не дизайнер, поэтому даже вглядываться не буду. Внедрить Synergy/Spree можно в любой e-commerce дизайн.
Если у Вас было сильно хуже, то возможно Вы попали на момент, когда кто-нибудь решил провести нагрузочное тестирование демки, для чего shared-хостинг конечно слабо предназначен.
Для разработчиков есть вполне хорошая документация — spreecommerce.com/documentation/overview
По поводу гибкости, даже интересно, какую это e-commerce задачу нельзя решить при помощи Spree? Сотни магазинов, от groupphotos.com до stickermule.com как бы прозрачно намекают, что возможности кастомизации в Spree практически ничем не ограничены.
Код Spree может и не идеальный, но на уровне лучших представителей OpenSource движков. Если есть сказать что-то конкретное на этот счёт, то прошу продемонстрировать в виде pull request'а, а не голословных обвинений.
Вы серьёзно? :-)
ror-e — это шоу одного человека, которому самому уже надоело развивать проект, если у вас есть желание впадать в жёсткую зависимость от его настроения или продолжать его проект самому, то вперёд. Свободу выбора никто не отменял.
Мобильная версия ещё пока в разработке, на iPad ещё не тестировали…
Спасибо
И эти капли в подавляющем большинстве на английском. При этом некоторые издательства умудряются нанимать для перевода людей, которые из качественной книги способны сделать белиберду.
Кроме того многие хорошие книги ждут хоть какого-то перевода по 5-10 лет
Вы уж извините, но писать программы транслитом — это и есть уровень быдлокодерства. К тому же что Вы будете делать с тысячами библиотек, которые уже имеют стандартный англоязычный API?
Ну так и отлично, добавить сюда ещё сотню наречий, немного предлогов, числительных и прочих частей речи и уже получается базовый технический английский, достаточный для чтения документации, с редким заглядыванием в google translate. Этот уровень в любом случае необходим всем, кто хочет делать в IT нечто большее, чем лабораторные работы по информатике, и его вполне достаточно чтобы особо не запариваться отсутствием русскоязычных материалов.
Вы всерьёз считаете, что языки программирования, библиотеки и фреймворки являются товаром?
Да их практически никто уже не продаёт, 75% популярных технологий — OpenSource, а ещё 15% — Freeware. Платное — узкоспециализированные языки и навороченные библиотеки под некоторые платформы, не будем тыкать пальцем. Суть в том, что студентам и тем более школьникам, ничего (кроме компьютера) покупать не нужно, чтобы изучать программирование.
Ну практически так. Русскоязычному сегменту его целевой аудитории гораздо важнее, чтобы движок продолжал отлично поддерживать морфологию русского языка и т.п., чем документация или сайт на русском.
Это не тезис, это аксиома, т.к. практически любая лицензия содержит пункт «AS IS», т.е. если Вам что-то не нравится, Вы не имеете никакого права требовать что-либо от разработчика.
Я же имел в виду, что для улучшения дел в российском IT, нужно создавать в России больше конкурентноспособных технологий, а не переводить документацию. Вот Вы знаете хотя бы 10 российских компаний, которые всерьёз спонсируют работу русских разработчиков OpenSource технологий? Я лично не знаю и вижу в этом гораздо большую проблему, чем в недостатке русскоязычных курсов по программированию.