Комментарии 137
Можете дать пару коментариев по производиельности? были ли какие-то тесты сделаны по этому случаю?
Конечно перед тем как что-то писать надо посмотреть сам магазин, но скажем сразу хочется заметить, что по моему мнению
— Управление макетами и компоновкой страниц магазина из админки;
данная вещь мало того, что не нужна так еще и вредна и вот почему: юзеру в шаблоны лазить не надо совсем ибо сломать легко а починить сложно. А человеку который способен править шаблоны делать это через вед ужасно утомительно и неудобно, всегда проце зацепит ьпроект с файлами к IDE и там все исправить.
Советую подумать над этим. По моему мнению идеальное решение — это то которое гибко в разработке и легко в администраировании. То есть не надо юзеру давать 100500 настроек в которых он запутается, лучше дайте разработчки возможность подключить и наладить все необходимое за максимально короткое время, это позволить максимально упростить и убыстрить процесс разработки. а юзеру работать с более менее кастомизированной под него системой.
Конечно перед тем как что-то писать надо посмотреть сам магазин, но скажем сразу хочется заметить, что по моему мнению
— Управление макетами и компоновкой страниц магазина из админки;
данная вещь мало того, что не нужна так еще и вредна и вот почему: юзеру в шаблоны лазить не надо совсем ибо сломать легко а починить сложно. А человеку который способен править шаблоны делать это через вед ужасно утомительно и неудобно, всегда проце зацепит ьпроект с файлами к IDE и там все исправить.
Советую подумать над этим. По моему мнению идеальное решение — это то которое гибко в разработке и легко в администраировании. То есть не надо юзеру давать 100500 настроек в которых он запутается, лучше дайте разработчки возможность подключить и наладить все необходимое за максимально короткое время, это позволить максимально упростить и убыстрить процесс разработки. а юзеру работать с более менее кастомизированной под него системой.
Я сначала подумал, что топик про фреймворк Apache Axis :-)
ws.apache.org/axis/
А вы почему название Axis выбрали?
ws.apache.org/axis/
А вы почему название Axis выбрали?
Мы никак не связаны с Apache Axis. Выбор названия был достаточно непрост ввиду того, что количество подобных решений огромно. Поэтому мы искали простое навзвание, которое начиналось с первой буквы алфавита.
Apache Axis это еще куда не шло. А вот то что Axis Communications — крупный производитель сетевых камер это уже хуже. Большая часть людей под «Axis» понимает именно фирму Axis Communications. В результате будет путаница и искать вас не удобно.
Данная компания работает абсолютно в другом сегменте. Еще можно добавить что Axis это также
Axis Communications, действительно, крупная компания в этом плане. У меня тоже при «Axis» ассоциации именно с ними и ведь никто не знает чем они вдруг станут заниматься позже. Если, например, им приспичит быть в похожей или той же области как «интернет магазин», то могут быть проблемы с выходом на рынок за пределами России.
ashop? :-)
Может у кого-то в команде электрогитара Music Man Axis?
Ошибка 500 Internal Server Error, увы. Хабраэффект?
Проект интересный, судя по всему, но ни фронтенд, ни бэкенд увидеть пока не удалось, только мельком по скриншотам на сайте, которые со скрипом открылись.
Проект интересный, судя по всему, но ни фронтенд, ни бэкенд увидеть пока не удалось, только мельком по скриншотам на сайте, которые со скрипом открылись.
Таки-да накрыл хабраэффект. Сейчас увеличиваем ресурсы хостинга.
Значит нужно работать над скоростью работы :)
Спорить тут сложно. Основаная причина в том что мы не работали на оптимизацией на данный момент. Поэтому кеширование практически не используеться. Но ближе к версии 1.0 конечно будет добавлено кеширование и проведена оптимизация быстродействия.
Эм… вы только что сказали прямым текстом «Ни в коем случае не ставьте нашу систему и не используйте её» )) Хороший маркетинговый ход.
Кеш это перво о чем должны думать разработчики магазинов и тому подобного ибо деньги = время, а чем дольше сайт будет висеть тем меньше денег и меньше покупателей постоянных. Да и ставить сервер за бешеные бабки ради того чтобы он держал нагрузку на магазин в котором нет кеша я думаю тоже не особо много желающих найдется ((
Кеш это перво о чем должны думать разработчики магазинов и тому подобного ибо деньги = время, а чем дольше сайт будет висеть тем меньше денег и меньше покупателей постоянных. Да и ставить сервер за бешеные бабки ради того чтобы он держал нагрузку на магазин в котором нет кеша я думаю тоже не особо много желающих найдется ((
В Zend Framework есть же кэишрование! Если вы пытаетесь создать хорошую платформу для разработки, так может стоит продемонстрировать удобство работы с ней на личном примере быстро запилив в движок кэш?
P.S. Выбрав Zend Framework как базу вы, имхо, промазали.
P.S. Выбрав Zend Framework как базу вы, имхо, промазали.
Как уже писал не раз текущая версия 0.8.6 и конечно же мы будет использовать родной кеш зенда.
Из опыта общения с заказчиками могу сказать, что их будем мало волновать версия. Им даже глубоко фиолетово на Zend Framework. Но их врятли обрадуют ошибки на сайте и уменьшение посещаемости из-за простоя сайта.
Свой продукт вы конечно сейчас ориентируйте не на конечного клиента, а по сути на разработчиков которые выберут его базой. Но проблемы клиента коснуться и вас когда конечный заказчик вынесет весь мозг разработчику и тот в будущем взмет что-то более стабильное.
Свой продукт вы конечно сейчас ориентируйте не на конечного клиента, а по сути на разработчиков которые выберут его базой. Но проблемы клиента коснуться и вас когда конечный заказчик вынесет весь мозг разработчику и тот в будущем взмет что-то более стабильное.
Не знаю как там в Zend, но я вчера настроил на своем проекте кеширование на симфони за пол часа. После этого скорость отклика с 60мс стала 4-8мс )
Так что думаю это не проблема
Так что думаю это не проблема
Это показатели времени как получены? Из самого проекта, из времени через тот же Firebug? Это полное время отработки одного запроса? Я так понимаю 4мс достигнуто для варианта, когда устанавливать коннект с СУБД не пришлось?
Это через Firebug. Я просто кеширую запрос, например на 1 минуту. После этого запрос полностью минует backend. Через минуту 1 раз обновляется
Если через Firebug, то видимо измерения происходят в условиях localhost. Потому как в сетевой оверхед в 4-8 мс поверить трудно.
Я так понимаю, что страницы такие, что можно позволить себе полностью скэшит запрос? Т.е. на странице визуально нет ни какой персонализированной инфы в духе «привет, username»?
Коннект к базе не устанавливается, если в кэше есть данные, так? Просто тот же pg_connect даже в случае локальной СУБД и коннекта по сокету требует около 2 мс.
Я так понимаю, что страницы такие, что можно позволить себе полностью скэшит запрос? Т.е. на странице визуально нет ни какой персонализированной инфы в духе «привет, username»?
Коннект к базе не устанавливается, если в кэше есть данные, так? Просто тот же pg_connect даже в случае локальной СУБД и коннекта по сокету требует около 2 мс.
Да. Про username вы правы. Но. Всегда есть аякс. Выносите все общие для всех куски страницы в аякс. Тем более что уже навигацию можно делать меняя полностью УРЛ и занося страницу в историю, но без рефреша страницы в браузере — history.pushState(...)
По поводу мс — да на локалхосте. Но сути это не меняет, я же имел в вижу время отклика от самого приложения, а не пинг
По поводу мс — да на локалхосте. Но сути это не меняет, я же имел в вижу время отклика от самого приложения, а не пинг
Те более самые нагруженные страницы обычно — это страницы списков всяких, одинаковые для всех пользователей. Если у вас идет что-то типо Привет {user.name} то этот тип кеша (он называется Revers Proxy SHARED cache) коенчно уже не подходит. Там вступает уже бекэнд, в котором конечно тоже все закешировано — шаблоны, классы и т.д.
Кеширование всего HTML или запросов к базе?
Смотря по ситуации. Всю страницу, части страницы, запросы.
Magento базируется на Zend
Наверное стоит привлечь админа для подкрутки/оптимизации хостинга. Текущий тариф сейчас какой кстати? Grid-Service?
А хаброэффект это фикция. Могу утверждать как админ, когда-то, виртуального сервера со стандартной WP на котором под блог был жестко отведен один рабочий процесс. Ни одной 50х для всех пришедших не было, более того, даже стандартный WP генерил страницу не дольше 2 секунду (хотя я думаю он был тут не виноват и дело в backlog-е сервера). У вас же сейчас либо 50х ошибки, либо страница генерится по 7-10 секунд. Будь я потенциальным клиентом, то у меня сразу же возник бы вопрос качества предлагаемого ПО. Не создавайте сами себе антирекламу.
А хаброэффект это фикция. Могу утверждать как админ, когда-то, виртуального сервера со стандартной WP на котором под блог был жестко отведен один рабочий процесс. Ни одной 50х для всех пришедших не было, более того, даже стандартный WP генерил страницу не дольше 2 секунду (хотя я думаю он был тут не виноват и дело в backlog-е сервера). У вас же сейчас либо 50х ошибки, либо страница генерится по 7-10 секунд. Будь я потенциальным клиентом, то у меня сразу же возник бы вопрос качества предлагаемого ПО. Не создавайте сами себе антирекламу.
Хабраэффект хабраэффекту рознь в зависимости от реального количества ломящихся людей, их плотности, распределения и т.п. :-) Возможно вам достался тогда меньший поток людей? Тяжело сравнивать «кого круче задидосили»…
Я не думаю, что к топик стартеру на сайт в течении часа зашло больше тысячи человек. И нужно думать в пике не было больше 2-10 запросов/сек. Если статику не раздавать тем же apache который и динамические запросы обслуживает, то плевая нагрузка. Но… но у автора статику шарашит тот же apache, поэтому конечно подкрадывается он, страшный хаброэфект. Которого можно было бы легко избежать. Поэтому я и говорю про админа.
А вы еще учтите что демо админки и фронтент стоят на слабых машинках ибо по своей сути предполагают очень маленькую нагрузку в отличии от основного сайта, так что тут не так сложно этот «хаброэффект вызвать».
Сайт Axis CMS на Drupal :)
Начинание хорошее, но вот plain-SQL в контроллерах вообще не порадовал (пример приложения).
А $this->_helper->json->sendSuccess(); в админке уберите и перепишите на AjaxContext
Кэш в отдельных actions просматривается, но работа с ним не впечатляет. Почему нельзя было сделать кэш в моделях, чтобы работа с ним была прозрачна?
Проект свободный? Участие в нем сторонних разработчиков (pull requests) допустимо???
А $this->_helper->json->sendSuccess(); в админке уберите и перепишите на AjaxContext
Кэш в отдельных actions просматривается, но работа с ним не впечатляет. Почему нельзя было сделать кэш в моделях, чтобы работа с ним была прозрачна?
Проект свободный? Участие в нем сторонних разработчиков (pull requests) допустимо???
Проект свободный. Участие сторонних разработчиков привествуеться.
Насколько я помню от plain-SQL давно уже избавились и практически все перенесено в модели. Если есть еще пожелание кидайте на форум.
Кеш еще только в начальной стадии разработке. Соотвественно ваши рекомендации также будут учтены.
Насколько я помню от plain-SQL давно уже избавились и практически все перенесено в модели. Если есть еще пожелание кидайте на форум.
Кеш еще только в начальной стадии разработке. Соотвественно ваши рекомендации также будут учтены.
SQL в контроллере: github.com/axis/axiscommerce_examples/blob/master/app/code/Example/CatalogFeed/controllers/IndexController.php
По кешу: советовал бы реализовать шаблон «Декоратор», чтобы в зависимости от конфига ваш метод Axis::single('catalog/category'), который, как я понимаю, возвращает модель, декорировал модель или просто возвращал ее.
Могу предложить посмотреть на то, как я это реализовывал не так давно: github.com/tankist/skaya/blob/master/library/Skaya/Model/Mapper/Decorator/Cache.php
Декоратор должен реализовывать один интерфейс с моделью, а все вызовы проксировать через __call (это если вкратце). Настройки cache_id и тегов берутся из DocBlocks-аннотаций.
По кешу: советовал бы реализовать шаблон «Декоратор», чтобы в зависимости от конфига ваш метод Axis::single('catalog/category'), который, как я понимаю, возвращает модель, декорировал модель или просто возвращал ее.
Могу предложить посмотреть на то, как я это реализовывал не так давно: github.com/tankist/skaya/blob/master/library/Skaya/Model/Mapper/Decorator/Cache.php
Декоратор должен реализовывать один интерфейс с моделью, а все вызовы проксировать через __call (это если вкратце). Настройки cache_id и тегов берутся из DocBlocks-аннотаций.
Почему не на втором Зенде, кстати? Да. он в бете, но и ваш проект как бы тоже…
В чем преимущества перед magento commerce?
Основаня идея была создать более простое и легкое решение. ме не целились на корпоративный рынок в отлиичии от магенто.
Ну судя по админке не очень получилось, без мануала заказчика надо будет неделю обучать, как минимум.
А по коду очень магенту напоминает (полугодовалой давности по крайей мере, когда я последний раз смотрел исходники), те же синглтоны везде, да и проблемы те же.
А по коду очень магенту напоминает (полугодовалой давности по крайей мере, когда я последний раз смотрел исходники), те же синглтоны везде, да и проблемы те же.
На какой рынок вы целились? Открыл редактирование товара и мне стало жутко от такого количества настроек… Я конечно допускаю что demo/demo это режим разработчика, и там много много всего включено, что не увидит конечный пользователь админ панели.
Но от увиденного был немножечко в шоке, зачем фотографии давать «заглавие» для каждого языка?
Мне кажется что делать один сайт для 6 языков одновременно, это сразу тупиковый путь.
Пользоваться таким интерфейсом становится жутко не удобно, работа с ним вызывает тоску и уныние. К тому же вот представьте ситуацию работает компания в России и у неё русский магазин, решили расшириться и запуститься в Казахстане или Белоруссии, нужно сделать магазин для этих стран на их национальных языках… В вашем понимании админ просто жмёт магические кнопки, включая иную языковую версию сайта, и заполняет везде поля для других языков. В теории все замечательно и удобно, на практике же, правильнее создать разные магазины для разных стран. Так магазинами и контентом рулить удобнее становится. Например завтра в Казахстане идёт распродажа, а в России наценка, как такую ситуацию обработать в вашей админ панели?
Открываю вкладку цена:
*Цена
*Налоговый класс(кстати что это?)
Стоимость
Видимо должен налоговый класс должен перемножаться с ценой и получаться стоимость, но ничего не происходит((( Если все должно работать так, как я предположил, то зачем поле стоимость доступно для редактирования?
Получается очень длинно, поэтому вердикт простой нужно упрощать интерфейс.
А то получилась программа от программистов и для программистов.
Человеку пользоваться таким будет очень сложно.
Но от увиденного был немножечко в шоке, зачем фотографии давать «заглавие» для каждого языка?
Мне кажется что делать один сайт для 6 языков одновременно, это сразу тупиковый путь.
Пользоваться таким интерфейсом становится жутко не удобно, работа с ним вызывает тоску и уныние. К тому же вот представьте ситуацию работает компания в России и у неё русский магазин, решили расшириться и запуститься в Казахстане или Белоруссии, нужно сделать магазин для этих стран на их национальных языках… В вашем понимании админ просто жмёт магические кнопки, включая иную языковую версию сайта, и заполняет везде поля для других языков. В теории все замечательно и удобно, на практике же, правильнее создать разные магазины для разных стран. Так магазинами и контентом рулить удобнее становится. Например завтра в Казахстане идёт распродажа, а в России наценка, как такую ситуацию обработать в вашей админ панели?
Открываю вкладку цена:
*Цена
*Налоговый класс(кстати что это?)
Стоимость
Видимо должен налоговый класс должен перемножаться с ценой и получаться стоимость, но ничего не происходит((( Если все должно работать так, как я предположил, то зачем поле стоимость доступно для редактирования?
Получается очень длинно, поэтому вердикт простой нужно упрощать интерфейс.
А то получилась программа от программистов и для программистов.
Человеку пользоваться таким будет очень сложно.
Интерфейсы будут конечно оптимизироваться.
Но если у вас нет необходимости испольщовать 6 языков, так это не значит что не нужно учитывать данный фактор. К примеру многие магазины севреной Европы используют 4-5 языков.
Созданые отельных магазинов для разных стран тоже доступно.
Но если у вас нет необходимости испольщовать 6 языков, так это не значит что не нужно учитывать данный фактор. К примеру многие магазины севреной Европы используют 4-5 языков.
Созданые отельных магазинов для разных стран тоже доступно.
НЛО прилетело и опубликовало эту надпись здесь
Статистика по переводу: Russian — ru_RU 104% complete Download (zip)
А чего не 146%? Говорят, в России эта цифра сейчас в моде.
А чего не 146%? Говорят, в России эта цифра сейчас в моде.
Планируете ли тесно интегрировать с 1С? Мне кажется это ключевой фактор при выборе cms для интернет-магазина, во всяком случае у меня так происходит, часто падает выбор в пользу ненавистного Битрикса, если клиент просит.
На чем думаете зарабатывать?
Забавно, установил эту CMS буквально неделю назад и вполне удобная уютная, конечно там надо понять как под неё самим модули писать ну и местами надо таки добавить всякие рашн моменты типа почты россии и т.д. странно что этого нет раз наши делали.
Пугает только одно, что будет после апдейтов, стоит ли вообще сейчас её юзать в продакшене, или ждать некого стабильного релиза после которого не нужно будет всё переписывать с нуля.
Пугает только одно, что будет после апдейтов, стоит ли вообще сейчас её юзать в продакшене, или ждать некого стабильного релиза после которого не нужно будет всё переписывать с нуля.
На данный момент мы поддерживаем совместимость версий при апргейде. Поэтому если вы не будете редактировать ядро, то проблем с совместимость быть не должно.
Если есть проблемы с написанием модулей и возникает необходимость переписать функционал ядра, тогда обращайтесь к нам на форум — мы всегда будем рады помочь. Оснонвая цель для нас это создание более гибкого и модульного приложения.
Если есть проблемы с написанием модулей и возникает необходимость переписать функционал ядра, тогда обращайтесь к нам на форум — мы всегда будем рады помочь. Оснонвая цель для нас это создание более гибкого и модульного приложения.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
shot.photo.qip.ru/004fT6-3009NDz/ Русский (Россия) и Русский (Украина)?
Из вопросов по системе планируется интеграция с русскоязычными платежными системами?
Из вопросов по системе планируется интеграция с русскоязычными платежными системами?
Да, планируем. Нам на данный момен нужна достоверная ифнормация про 2-3 наиболее популярные платежные системы с точки зрения применения в средних и небольших магазинов рунета.
работаю ежедневно с интернет магазинами. Мой совет:
1- Пластиковые карточки
2- Яндекс
3- Вебмани
4- Квитанция сбера
5- Курьеру наличкой
В принципе это основное, но как вариант можно написать модуль одной из платежных систем типа Робокассы
1- Пластиковые карточки
2- Яндекс
3- Вебмани
4- Квитанция сбера
5- Курьеру наличкой
В принципе это основное, но как вариант можно написать модуль одной из платежных систем типа Робокассы
В базовые возможности — введите возможность отправлять заказ на почту продавцу без факта оплаты вообще. Это один из самых востребованных пунктов на территории СНГ, но тем не менее очень мало магазинов дают такую опцию.
Из минусов:
1- Для чего нужна временная зона? (Если все таки нужна проставьте (+1 +3 +5) а то очень проблематично найти свое)
2- При выборе локализации автоматически возможно сделать подстановку валюту (рубли) по умолчанию в списке
3 — Рубль СССР
Из плюсов:
1- При установки понравилась возможность выбора произвольного адреса для админки
Дальше пункта «Axis успешно установлен» проследовать не получилось белый экран на сайте + белый при попытки входа в админку. Помогите разобраться в чем проблема.
1- Для чего нужна временная зона? (Если все таки нужна проставьте (+1 +3 +5) а то очень проблематично найти свое)
2- При выборе локализации автоматически возможно сделать подстановку валюту (рубли) по умолчанию в списке
3 — Рубль СССР
Из плюсов:
1- При установки понравилась возможность выбора произвольного адреса для админки
Дальше пункта «Axis успешно установлен» проследовать не получилось белый экран на сайте + белый при попытки входа в админку. Помогите разобраться в чем проблема.
Почему Zend Framework, а не Yii?
А если бы было на Yii задали бы вопрос: «Почему Yii, а не Symfony?»?
Нет, не задал бы. Yii лучше и того и другого.
Сразу видно профессионала широкого профиля.
На Yii это был бы единственный качественный движок магазина. На зенде их много, один Magento чего стоит. А на Yii пока тихо
Если нужен еще один на Yii, то это не проблема. уже некоторое время валяется движок модульный, может дойдут руки оформить код нормально и выложить на гитхабе. Если это действительно надо. На решение «все из коробки» этот движок не претендует, но его довольно легко расширить за счет модулей, писался из расчета облегчить жизнь разработчику, тобиш мне.
Fesor, вы почитайте русское сообщество yiiframework.ru/forum/, там очень много людей пишут о магазине на Yii
Проект заинтересовал. Только вот жаль, что нельзя продавать цифровые товары, такие как ключи, пароли и так далее.
И, к сожалению, нет популярных российских платежных систем (webmoney, Яндекс, Qiwi) из коробки.
вопрос1: может ли поставить себе такого зверя человек, далекий от веб программирования?
вопрос2: поддерживаю предыдущего оратора. Стоит ли ожидать добавление яндекс денег, киви, вебмани и т.п.? Если да, то когда, т.к. это, мне кажется, довольно важно. Кэшируется там или нет, аякс там через jQuery — все это ерунда для пользователя, если нет webmoney, которым он привык пользоваться и доверяет.
вопрос2: поддерживаю предыдущего оратора. Стоит ли ожидать добавление яндекс денег, киви, вебмани и т.п.? Если да, то когда, т.к. это, мне кажется, довольно важно. Кэшируется там или нет, аякс там через jQuery — все это ерунда для пользователя, если нет webmoney, которым он привык пользоваться и доверяет.
По внутренностям напоминает Magento, типа вот такой кусочек, например:
но и видно сразу, что много и отличий — самописная архитектура.
Удачи с проектом, работы еще очень много :)
Кстати, в Magento 2 эволюция заставила отказаться от алиасов вроде 'module/some_model'
$model = Axis::model('catalog/product_option')
но и видно сразу, что много и отличий — самописная архитектура.
Удачи с проектом, работы еще очень много :)
Кстати, в Magento 2 эволюция заставила отказаться от алиасов вроде 'module/some_model'
Спасибо за пожелания. Мы будем очень благодарны если вы скажете в чем была причина отказа от такого подхода. И будет ли сохранена текущая гибкость переопределения любой модели в магенто?
С увеличением количества модулей гораздо дольше проходят xpath-выборки по конфигу + больше самих выборок просто за счет того, что классов используется больше. Если убрать алиасы, то возрастает производительность системы.
Magento 2 есть на Github: github.com/magento/magento2
Реврайт классов в силе, создание объектов по-прежнему через фабрику:
Кстати, просмотрел код подробнее — ребята внизу правы — много заимствований из Мадженто. Поэтому лучше называть Axis форком и копирайты ставить.
Magento 2 есть на Github: github.com/magento/magento2
Реврайт классов в силе, создание объектов по-прежнему через фабрику:
$model = Mage::getModel('Mage_Catalog_Model_Product');Кстати, просмотрел код подробнее — ребята внизу правы — много заимствований из Мадженто. Поэтому лучше называть Axis форком и копирайты ставить.
Что заставляет людей по-прежнему писать сайты на php, когда есть такие вещи как rails или django?
Легкий хостинг, низкий порог вхождения, как варианты.
А еще есть perl, asp, c, c++ и много других умных слов. Вы бы лучше что умное или полезное (а лучше, и то, и другое) сказали, чем хвалиться знаниями названия нескольких из них. И да, мне не нравятся ни руби с рельсами, ни, тем более, питон с джангой.
А давайте вот немного похоливарим. Называйте причины по которым это необходимо писать на ruby?
На самом деле в последних версиях PHP стал похож на приличный язык. Потихоньку подтягиваются библиотеки и фреймворки, переписываются CMS.
типа на django легко писать сайты? да как и любую CMF надо изучать… тот же друпал или маженто, все равно надо знать как писать модули и кастомизировать, без этого никак
Напишите, а мы будем пользоваться
Вы сравниваете язык программирования с фреймворком
Node.js сейчас хорошо развивается, вот бы на ExpressJS написали такой магаз =)
Node.js сейчас хорошо развивается, вот бы на ExpressJS написали такой магаз =)
ребята помогите с установкой все установилось, а былые экраны, как на сайте так и по адресу админки
На мой взгляд, выбор в качестве основы админки ExtJs версии 3 не совсем оправдан. В общем админка, да и фронтэнд как — то не шустро работают.
НЛО прилетело и опубликовало эту надпись здесь
86 запросов к серверу, в панели администратора, из них: 11 CSS, 41 JS, 29 IMG.
Не пробовали в спрайты картинки собрать?
CSS и JS по максимуму в один файл и вырезать все комментарии.
Не пробовали в спрайты картинки собрать?
CSS и JS по максимуму в один файл и вырезать все комментарии.
Спасибо за информацию, обязательно погоняю этот движок.
Скажите, а поддержка PostgreSQL планируется?
Скажите, а поддержка PostgreSQL планируется?
СЕО имя должно зависеть от языка.
Или можно ещё добавлять суффикс -en, -ru, -el,…
При выключении визивик должны пропадать связанные с ним кнопки.
Саму панель визивик надо уменьшить (или увеличить окно по ширине, чтобы больше кнопок в строку влезало). Сейчас слишком много места занимает.
Совершенно не понятна логика работы с опциями и их наличием.
Например, как завести футболку, у которой есть 3 цвета и пять размеров и как управлять складом в этом случае?
В целом понравилось — есть хорошие идеи (особенно порадовало переключение языка при редактировании товара).
Только интерфейс надо всё-таки доработать и мелочи пофиксить.
Когда планируете первый релиз?
Или можно ещё добавлять суффикс -en, -ru, -el,…
При выключении визивик должны пропадать связанные с ним кнопки.
Саму панель визивик надо уменьшить (или увеличить окно по ширине, чтобы больше кнопок в строку влезало). Сейчас слишком много места занимает.
Совершенно не понятна логика работы с опциями и их наличием.
Например, как завести футболку, у которой есть 3 цвета и пять размеров и как управлять складом в этом случае?
В целом понравилось — есть хорошие идеи (особенно порадовало переключение языка при редактировании товара).
Только интерфейс надо всё-таки доработать и мелочи пофиксить.
Когда планируете первый релиз?
реинкарнация os-commerce что ли
таже хрень тока в профиль
таже хрень тока в профиль
Очень заметно влияние Magento — даже картинки товаров оттуда и интрефейс очень похож)) а как писали выше — и в коде много аналогий :)
да там отовсюду заметно влияние
только смысл этого проекта по моему мнению — нулевой
тот же Magento довольно таки неплохой если к нему напильник соответствующий приложить
только смысл этого проекта по моему мнению — нулевой
тот же Magento довольно таки неплохой если к нему напильник соответствующий приложить
Несомненно нулевой, использовать его нету никаких оснований — уж лучше Magento Community взять, там хоть гарантированное развитие, другой уровень качества и поддержка сообщества. Хотя магенто тоже не фонтан — слишком перемудрили, высокий порог входа для разработки и дорог в разработке/поддержке
Про смысл проекта пусть решают пользователи. В ходе разработки мы смотрели далеко не только Magento, но еще многие другие проекты. Как уже писалось выше подобных решений десятки.
Ребята, а как вы прокомментируете грубое нарушение авторских прав Magento?
Я в общем-то не юрист, но подозреваю, что оно все-таки имеет место, т. к.:
1) Вы же не будете на этом сайте, где полно IT специалистов, способных самостоятельно проанализировать суть вещей, отрицать, что ваше решение все-таки основано на Magento?
Я был удивлен, обнаружив, что достаточно большая часть исходников — «рерайт» соответствующих классов Magento и библиотеки Varien, типичная картина — подчищен лишний в проекте функционал, добавлено немного своего и заменена шапка с лицензией. Хотя да, есть места, где все переписано по-другому.
2) В то же время, каких-либо ссылок на авторов «материала для вдохновения» нет, лицензия уже не OSL 3.0 и даже больше, на официальном сайте вы говорите, No, Axis is not based on Magento.
?
Я в общем-то не юрист, но подозреваю, что оно все-таки имеет место, т. к.:
1) Вы же не будете на этом сайте, где полно IT специалистов, способных самостоятельно проанализировать суть вещей, отрицать, что ваше решение все-таки основано на Magento?
Я был удивлен, обнаружив, что достаточно большая часть исходников — «рерайт» соответствующих классов Magento и библиотеки Varien, типичная картина — подчищен лишний в проекте функционал, добавлено немного своего и заменена шапка с лицензией. Хотя да, есть места, где все переписано по-другому.
2) В то же время, каких-либо ссылок на авторов «материала для вдохновения» нет, лицензия уже не OSL 3.0 и даже больше, на официальном сайте вы говорите, No, Axis is not based on Magento.
?
Обьясните что конкретно вы имеете ввиду под нарушениями? Использование Zend и MVC арзитектуры? Страуктура расположения файлов?
Навскидку кусок кода: diff (слева фрагмент класса lib/Varien/Object из Magento, справа фрагмент кода из library/Axis/Object).
Наверно совпадение и вообще, разве можно написать такую простую вещь как-то по-другому, да? :)
Наверно совпадение и вообще, разве можно написать такую простую вещь как-то по-другому, да? :)
думаю маджентовцам глубоко по*й на это, они далеко впереди даже со своими тараканами
Есть ли возможность расчитывать стоимость отправки почтой РФ в зависимости от индекса/региона и веса заказа? Для русский ИМ это немаловажно…
Как frontend demo посмотреть то? Сейчас там стандартная заглушка апача.
Разработка — это хорошо. Но все крутости ничего не стоят, пока ваш продукт не получит широкое распространение у разработчиков. Как случилось с simpla, которая так отлично стрельнула после презентации… потом стухла
Первым делом побежал искать шаблонизатор — не нашел :) Уважаю.
очень не понравилась реализация каталога
не нашел инфы, как сделать импорт/экспорт в каталог
Axis послдение обновление 2012-06-11 (
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Axis — интернет магазин своими руками