С магазинами в Тайпе по-прежнему всё глухо?

[Ивано++]

И все таки приходится сново возвратиться к данной теме...

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

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

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

Самый четкий и единственный вариант , который у меня оставил только положительные эмоции
случайно наткнулся - это http://simplacms.ru/... Здесь есть все что нужно, и ничего лишнего...

Что скажите - можно ли это считать идеалом интернет-магазина?
Или есть еще вещи, на которые стоит обратить внимание - имею в виду по функционалу
- который бы был полезен?

По идее - впринципе здесь есть все, что необходимо...
Просто может быть что-то упускаю из вида?

[Андрей Аксенов]

Да, неплохой скрипт для магазина. В нем, вообщем-то и ответ - что долджно быть.
Кстати, в Мультишоп что-то схожее, но управляется он со страниц сайта - нужно лишь зайти под пользователем-администратором, и появляются аякс-меню управления... это к слову о реализации интерфейса - не все бакенд...
Что для меня актуально - импорт-экспорт товаров и резервирование, я считаю, это обязательный модуль. Сюда же - выгрузка списка товаров в виде актуального прайс-листа - что-то вроде xml, yml и т. п.
Опять же, выгрузка и работа с финансами и уровень взаимодействия с бухгалтерскими программами - в реальном времени или импорт/экспорт.
Управление мета-тегами из свойств товара. Формирование меню категорий, хлебных крошек.
Фильтрация (может и аякс), тесно связанная со свойствами товаров.
Далее - настройки, здесь разброс большой - кому-то нужно больше, кому-то меньше... Валюта, способы доставки и оплаты, а также их связи.
Еще - модуль статистики заказов.
Остальное можно настроить и существующим функционалом TYPO3: отзывы, рассылки, подписки, те же мета-теги, тег тайтл, авторизация и функционал кабинета пользователя, новости с их рассылкой и подпиской, всевозможные формы, опросы и прочие приблуды - тут тайпо3 на высоте...
Узким местом здесь становиться взаимодействие с базой данных и кеширование - у тайпо очень много запросов...
Перегружать сайт сбором статистики не следует - для этого есть всякие яндексы и гуглы с вебмастерами.
Вот как-то так...

[Ивано++]

Тогда думаю что более смысла что-то искать нет - и полностью поддерживаю Ваше мнение.

И тогда так и получается самым Важным является же опять вопрос именно экспорта/импорто товара - что бы они были всегда актуальными... Ну и к заказам тоже самое... Не совсем понял только что значит резервирование?

--
А по поводу кэширования в typo3...
Я все более и более склонялся к такой теме, что бы страницы (готовый кэш) включать на уровне localconf - единственный минус - это 100% кэш (0 запросов к БД, прктически 0% работы php, нагрузог на хостинг 0) - и как следствие, страница не динамичной получится.

Но потом отказался от этой идеи...
И пришел к следующему выводу - если у меня сайт быстро грузится < 1 секунды на typo3 и даже не на VPS (работает на FLUID, TS, и стандартных шаблонах) - значит можно оставить... Конечно без VPS-уже не потянет 500 и более страниц - т.к. на них будут кроме посетителей, заходить еще роботы - и будет выбиваться ограничение на запросы и работу скриптов...



--
А по поводу FE-модулей так и получается что в любой CMS это дело техики и времени... У меня была один раз задача сделать выгрузку товара (10 штук) для яндекс.маркета на bitrix - не скажу, что мучился - но сделал не элегантно.

Хотя идея была в следующем - просто к товарам добавил поле галочку "Данный товар участвует в Яндекс.маркет" - а если в typo3 создал бы новый тип страницы специально для яндекс.маркета - куда бы кэшированно выгружал список данных товаров...


--
Тогда оставляю себе на заметку функционал http://simplacms.ru/
И больше не терзаюсь данной темой (в т.ч. в голове)...
Просто CMS-магазинов много море - а интересного, компактного, по делу и сущестову очень мало оказалось...

Еще интересный : shop script 5
Спасибо.

[Ивано++]

И с другой стороны...
Раз мы затронули тему кэшировани...

Не совсем понимаю - почему для многих это является проблемой производительности... Ведь по идее кэширование, что на файлах, что на БД не имеет никакой раздници...

Что запрос SELECT
Что запрос к файлу . по скорости одно и тоже...
Ну если конечно не считать запредельные размеры Баз данных - ОЧЕНЬ ОЧЕНЬ ОЧЕНЬ БОЛЬШИЕ...

Помню в инете как то читал заметку одного парня - он ТИПа тестил mysql-возможности - на примере вставки 1 000 000 или миллиарда справочника телефонов - но суть не в количестве, а во времени, за которое этот запрос INSERT у него выполнился (сутки, или трое) - и он удивлялся "Блюдь - как же так - ня это mysql-сервер"...

Я многого до сих пор не понимаю:

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

По идее - почему typo3 грузится определенное время - это все из за for, и foreach (грубо говоря)- когда происходит переборка массивов - вот и все...

Другое дело когда идут сложные запросы
SELECT JOINT - и прочая перекрестщина...
типа как здесь:

PHP код:

SELECT DISTINCT tt_news.uid, tt_news.*
FROM tt_news 
LEFT OUTER JOIN tt_news_cat_mm ON tt_news.uid = tt_news_cat_mm.uid_local
WHERE
    1=1 
    AND (tt_news_cat_mm.uid_foreign IN (32,7,1,33,60)) 
    AND tt_news.sys_language_uid IN (0,-1) 
    AND tt_news.pid > 0  
    AND tt_news.uid NOT IN (11305) 
    AND tt_news.pid IN (85,86,87,88,137,369,520) 
    AND tt_news.deleted=0 
    AND tt_news.t3ver_state!=1 
    AND tt_news.hidden=0 
    AND (tt_news.starttime<=1352798034) 
    AND (tt_news.endtime=0 OR tt_news.endtime>1352798034) 
    AND (tt_news.fe_group='' OR tt_news.fe_group IS NULL OR tt_news.fe_group='0' OR (tt_news.fe_group LIKE '%,0,%' OR tt_news.fe_group LIKE '0,%' OR tt_news.fe_group LIKE '%,0' OR tt_news.fe_group='0') OR (tt_news.fe_group LIKE '%,-1,%' OR tt_news.fe_group LIKE '-1,%' OR tt_news.fe_group LIKE '%,-1' OR tt_news.fe_group='-1'))
ORDER BY datetime DESC
LIMIT 7 


И честно признаться я вообще не совсем-то понимаю зачем в tt_news такие вот запросы есть...
Да еще и эта недопирамида MM.
Hidden, deleted да limit - и этого достаточно выше крыши...
Ну или конечно если хостинг позволяет - то это другое дело...

Поэтому чем проще запросы тем лучше...
А время на for и foreach - это неизбежное...

Ведь на сколько мне известно mysql - это теже файлы (только два - одни структура, другой данные).
Вот представим мы делаем просто запрос к файлу casche.temp - он у нас выполнится за минимум милисекунд.
А если нам еще надо разобрать данные полученные из него, да еще что-то запросить и присоединить из файла casche2.temp...

Что через БД, что через файловые системы - раздницы никакой не будет...

[-=UncleByte=-]

Симпла пока еще довольно сырая и дорожает от версии к версии. CS-Cart умеет гораздо больше и лучше за те же деньги.

[Ивано++]

Сообщение от -=UncleByte=-

Симпла пока еще довольно сырая и дорожает от версии к версии. CS-Cart умеет гораздо больше и лучше за те же деньги.

Смотрим, изучаем...
Тоже интересная штука - но в нем как мне показалось больше лишнего...

[-=UncleByte=-]

Ага, самое ненужное это, конечно, обработка картинок категорий, чего добиться от Симплы в принципе пока не получается не дописав чего-то своего.

[Ивано++]

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

По идее хранение товаров можно организовать в виде одной таблицы, где в данной можно создать 1 поле (аналог doktype для pages, CType для tt_content) - и мы сможем создавать в рамках одной таблицы разные товары с разным набором свойств....

Так обычно и делают.
Но вот у меня есть один момент, который в голове не совсем укладывается.

К примеру как совместить товары с категориями.
Или к примеру, у нас будет еще какая-то 3-тья таблица....
В которой мы будетм хранить к примеру город (или еще что-то)...

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

Но вопрос в том, будут ли у бухгалтерии данные таблицы - и как они к примеру хранять то, к какой категории принадлежит товар?

[Андрей Аксенов]

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