Модуль интернет магазина

[cmsservice]

Когда создаешь новый каталог, то первый диалог который появляется со свойствами каталога (такой с тремя вкладками), вот в нем и заполняй.

[Count_Raven]

POedit вообще никак не связан с PHP, т.е. даже близко никак не связан.
Это редактор для gettext, сам формат появился еще в то время, когда PHP не существовало.
Есть сборщики из командной строки, само собой, а POedit это их GUI.
Ничего общего даже близко к PHP все это не имеет.

Стандартно gettext работает с функциями перевода, которые начинаются с символа "_". Так он парсит код.
В Concrete5 эта функция называется "t". Нужно настроить программу на "t" и после парсинга вы увидите все строки, которые можно перевести.
Либо просто откройте файл для перевода, который был сгенерирован ранее. Если вы делаете свой проект и ипсользуете это, то, чтобы создать свой файл перевода - просканируйте папку описанным выше способом.

[guyasyou]

Кстати, если кому интересно, вот модуль- уже рабочий, но не универсализирован, сроки поджимают- делал под конкретный заказ. Но подогнать под себя дело нескольких минут...
И админки тоже нету, пока нечего там настраивать.

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

Если есть замечания или советы- пишите.

Изначальная задумка такова:

1 Товар = 1 страница

мультивалютность, при чем валюта на юзера привязана будет, а не на магазин вцелом(пока задана как константа) (теоретически можно каждый заказ со своей валютой покупать)

кастомизация товара при покупке, например выбор цвета (пока не реализована ни капельки)

ну и расширяемые методы оплаты конечно(пока не реализована ни капельки, вообще нет оплаты)

Что сделано:
Вроде как корректно устанавливается
Работает блок вывода списка товаров (page list переделанный)
Работает корзина и ajax-штучки. (вывод корзины будет вынесен в elements, так как надо будет в других местах выводить его.)

P.S. "...только не по лицу!!!"

UPD: Перезалито. Убрал пару лишних строк кода и русифицировал.

[vbnm]

ТУт МЧ предлагал сделать ему шаблон на основе квери кажись, вот с него можно было бы сделать толковый МГ. Причем интересный уже в начале)) Чисто из за вида))

viewtopic.php?f=17&t=464

Категории товаров ты собираешься разбивать на основе Тегов?

Карта сайта эт хорошо, но она не покажет наиболее популярные. Так же могут быть товары которые содержат в себе параметры нескольких категорий.
Так же может быть влом организовывать на каждую категорию основную страницу с послед подстраницами, когда можно просто фильтровать на основе тегов. А если это еще и облако, то ваще. Так что карту сайта можно отодвинуть на второй план, и сделать упор на теги, для ускоренной навигации. Вместо создания опред категории товара(а это целая страница с последующими подстраницами), просто и логично внести всего лишь один тег, который потом и будет использован на многих страницах.

[guyasyou]

У меня был опыт работы с тегами ( более 2000 товаров), технически все логично, а на деле фигня получается, так как вводит то теги человек... Один и тот же предмет может быть назван по разному, это чтоже, все синонимы вводить? Теги, всетаки, дополнение к поиску.
Плюс, когда много тегов, много работы по поиску.
И теги не показывают популярное, они показывают наиболее часто встречающеяся слово. Делаю машазин сувениров, значит каждый товар содержит тег "сувенир"- лишеяя информация помоему... Облако тегов с рангами по популярности интересен блогам, например- показывает тренд, а в магазине врядли.

Хочется тегов? Пожалуйста, добавить атрибут, и запрашивать page list с фильтрацией по атрибуту, получит страницы- profit

[Count_Raven]

Карта сайта эт хорошо, но она не покажет наиболее популярные.

Покажет. Популярность товара ничего общего не имеет со страницами или с тегами. Это лишь реализация представления. Почему мы не можем показать популярность товара? Что мешает? Может я чего-то не понимаю?

Так что карту сайта можно отодвинуть на второй план, и сделать упор на теги, для ускоренной навигации.

И для увеличения нагрузки на сервер.

Вместо создания опред категории товара (а это целая страница с последующими подстраницами), просто и логично внести всего лишь один тег, который потом и будет использован на многих страницах.

Да как бы никто не мешает использовать и то и другое одновременно. Однако же, теги сделаны немного для другого и строить на них структуру мне кажется весьма сомнительной идеей. Их лучше использовать для поиска.

[cmsservice]

Вот расспорились.

Если углубится в теорию, а разрабатывая магазин/каталог, в нее полезно углубиться, мы увидим, что есть 2 основных типа организации каталогов:

1. иерархический
2. фасетный

1. Иерархическая организация
Это как раз расположение товаров в жестко заданной иерархии признаков, т.е. то как мы видим расположение страниц в карте сайта. Основные черты иерархического типа:

• Одномерный в пределах уровня
• Навигация по жестко заданной иерархии
• Отражает способ мышления владельца сайта

Такая организация каталога проста в реализации и применяется на сайтах, с относительно небольшим количеством единиц каталога (например товаров) и небольшим количеством признаков у единицы каталога.

2. Фасетная организация
Частный случай фасетной организации - классификация по тегам. Понятно, что в серьезных каталогах с такой организацией присутствует большое количество признаков классификации (фасетов) и грамотная организация работы с такими каталогами. Основные черты фасетного типа:

• Многомерный
• Интерактивный
• Дает доступ к возможным вариантам
• Позволяет клиенту пойти своим путем при выборе товара
• И самое важное: совпадает с моделью покупок клиента

Такая организация применяется в больших промышленных каталогах, насчитывающих десятки и сотни тысяч единиц каталога. Пример: Яндекс.Каталог, Яндекс.Маркет, Amazon, Ebay, Nike и т.п. И да, такой каталог может прикидываться иерархическим, но на самом деле это всего лишь выборка по одному или нескольким фасетам.

[Count_Raven]

Мы не об этом. Мы о реализации на Concrete5. Можно сделать и то и другое, но только модель тегов из Concrete5 в данном случае считаю плохим вариантом. Если уж так надо, то нужно создать свою систему, теги из Concrete5 тут не тянут.

[cmsservice]

Да, организация тегов в С5 сделана через ж... короче, но сама идея фасетного каталога это сейчас тренд и на C5 ее реализовать можно. Мы ищем подходы и если будет заказчик с таким каталогом, то обязательно реализуем.

[Count_Raven]

Да, организация тегов в С5 сделана через ж... короче, но сама идея фасетного каталога это сейчас тренд и на C5 ее реализовать можно. Мы ищем подходы и если будет заказчик с таким каталогом, то обязательно реализуем.

Да не вопрос. Тем более, что я сторонник более "классического" подхода, поэтому не использую страницы в Concrete5 для работы с какими-либо объектами. Я создаю свои модели объектов и категории атрибутов если нужно. Со своими объектами я могу делать все, что угодно. Что я буду делать со страницами, если они станут непригодны? Что я буду делать с ними если возрастет нагрузка? Если понадобятся серьезные изменения?
Своя база, свои объекты, все свое. Concrete5 выступает только в роли фреймворка со всеми базовыми вещами (управление контентом, кэширование, управление пользователями, интерфейс, шаблонизатор, все основные плюшки/хелперы и т.д.). Страницы Concrete5 мне нафиг не нужны в таких вещах, как и теги - по сути, это бонус, чтобы клиент мог разместить "About Us" и добавить галерейку в удобной для него обстановке

[cmsservice]

ИМХО это вопрос подходов, другими словами "все в голове". Страница, такой же обхъект, который еще и обеспечивает кучу базового функционала. Если не упираться в него, то можно на базе этих объектов рождать свои, которые можно использовать как угодно. В общем - к одной цели всегда ведет несколько путей.

[Count_Raven]

ИМХО это вопрос подходов, другими словами "все в голове". Страница, такой же обхъект, который еще и обеспечивает кучу базового функционала. Если не упираться в него, то можно на базе этих объектов рождать свои, которые можно использовать как угодно. В общем - к одной цели всегда ведет несколько путей.

Так я же не с ноля пишу. Я использую Concrete5 как фреймворк. Мои объекты наследованы от чего? Правильно, от объектов ядра Concrete5. Весь базовый функционал я имею у своих объектов. Просто не использую страницы. Все удобности беру от Concrete5, иначе нафига оно бы нужно было мне? Такими темпами я бы вообще свалил, так как мне тогда уже по душе Symfony или Silex/Flint. А последние мои чаяния это Node.js. Т.е. естественно, что я делаю ответвления от Concrete5 чтобы мои объекты были совместимы с системой и для них работают все стандартные методы вплоть до того, что любой атрибут из Concrete5 можно прицепить к моему объекту через панель управления. Для этого просто нужно создать один файл - категорию атрибутов для моего объекта. Все системные модели, поисковые фильтры, кэш и т.д. прекрасно живут с моими объектами, так как они родные для Concrete5. Никто же не говорит про то, что нужно писать с пустого места.

P.S. Заофтопили конкретно.

[guyasyou]

Неведомый баг.

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

Этот "пробел" прописывается как только я подключаю модель Товара

Код: Выделить всё

Loader::model('easy_shop_product', 'easy_shop');

Я вставлял

Код: Выделить всё

print '<div class="debug"></div>';

В разных местах кода, пробел прописывается сразу после require_once в Loader-е.
Скопировал его в буфер, вставил -оказалось вопросительный знак

Что его может прописывать?

[vbnm]

Что его может прописывать?

пока элементарное
Иногда, когда закатываешь PHP в ХТМЛ, иль наоборот, то может вылезти и скобка и знак вопроса...неверный, лишний код, в С5 это часто происходит.
Можно еще вспомнить и то, возможно где -то использован знак вопроса, который был напечатан при раскладке клавы на русском языке.

вставил -оказалось вопросительный знак

ка мы наем, если кодировка неверная у файла, то лезут кракозябры вместо текста, а если это не целый текст, а всего лишь один символ, но с неверной кодировкой? То мы получим всего один знак вопроса, вместо него. Попробуй принудительно выставлять в броузе кодировку, затем помотри что будет с ентим знаком, ну а после, если он выдаст ЧПУ символ, ищи его в коде))

[vbnm]

модель тегов из Concrete5 в данном случае считаю плохим вариантом.

мне показалось, или же я видел тут тему, что кто-то делал мод облако тегов?
В облаке тегов обычно выделяются наиболее запрашиваемые теги, цветом, размеров, текстурой и прочими средствами.

И для увеличения нагрузки на сервер.

все видели Умный поиск в админ панели, но ни кто еще не протестовал против него, а ведь он по сути самый грузовой.

Кстати, никто с него мод не делал для открытого пользования гостями сайта?
Вообще эта технология на офф сайте используется достаточно широко. Вместо страницы с записями в блоге, мотается лента поисковика по релеватности. Тож самое и в ВК, ОК.

Я не против и карты и тегов. Но теги проще в плане того, что не надо думать о структуре каталога товаров, куда и какой поместить. Сделал стандартную запись, указал тег и все, больше не паришься.