|
С магазинами в Тайпе по-прежнему всё глухо?
Собственно сабж!
Есть ли какие-нибудь подвижки или как и раньше - без большого напильника к большинству магазинных экстов не подойти :( Остаётся либо "случать" Typo3 с той же Magento, либо фиксить баги? Хотя всегда есть вариант сделать на любимом в рунете битриксе :D |
Мне вот интересно - сколько магазинов сделанных на любой CMS - имеют реальный комменческий усхех - т.е. являются действительно продающими, а не глухо сидящими - где-то в 100-1000 забытых позициях поисковых мащин...
Ведь есть две ситуации 1. фирме нужен реально-продающий магазин (с интеграцией) - и тогда там сидит собственный штат программеров - которые делают все от и до только под нужды фирмы и бухгалтерии, а также налоговых органов - и у них супер-пупер магазин... Зачастую также есть человек - который "по связям с общественность" - который и купит ПО, и настроит его за счет других, и продвинет за счет услуг сторонних организаций... А главное под супер пупер также имеется в виду что это в топах поисковиков... Хорошие примеры - любой интернет магазин по запросу "купить телефон nokia"! - и 10 первых примеров. 2. Либо это студия-штамповик/фрилансер - которая делает магазин с бюджет где-то от 15 000 руб. до 100 000 руб. используя заготовку (больше!? а малый и средний бизнес готовы платить за такие риски - ведь обычно как происходит - что-то сделали, за что-то заплатили и на этом весь проект закончился - он висит в интернете - как могильный камень над плитой) - и это не включая стоимость продвижения... А стоимость продвижения это отдельная тема - попробуй те со своим интернет-магазинчиком обойти конкурента-акулу и выдвинуть его хоть куда-нибудь - там только успевай платить продвигающей стороне... Это Вам еще очень крупно может повести - что заказчик является областью - где конкуренция как сайтов, так и реальных прдовцов терпимая... Сколько малого и среднего бизнеса будут готовы платить? Имеют ли они централизованое размещение своих товаров? Поэтому вывод очевиден - в основном по второму варианту бизнес-магазины малому и среднему бизнесу ныжны для "визитки". Это все затеял я к следующему вопросу вот если бы Вы были моим заказчиком - сколько бы вы готовы были мне заплатить за создаие действтиельно хорошего магазина именно на typo3 - без всягих там магенто и прочего... - который интегрируется с о пределенной БД - который позволяет настраивать поля под товары магазина - на 1-2-3 раз обслуживается любыми "модераторами-девушками"... - которая будет иметь внутренную логику работы магазина (типа просмотр текущих заказов и т.п.) - который имеет разные формы оплаты для покупателей - который имеет понянтую для посетителей навигацию... - который обеспечивает вывод ваших товаров на сайте... - и самое главное которое действительно будет дополнением typo3 - в единой стилистике, без сложных настроей, без OTHER-дизайна - т.е. все как единое целое... -- про продвижение пока не идет разговор - только про сайт... -- ДАЖЕ СВОИМ ЗЛЕЙШИМ ВРАГАМ НЕ ПОСОВЕТУЮ ИСПОЛЬЗОВАТЬ существующие Commerce и прочие эксты магазинов для typo3. ----- Magento - платформа для роста вашего бизнеса! Magento - это профессиональная, многофункциональная платформа для электронной коммерции с открытым исходным кодом, которая предлагает продавцам полный контроль над внешним видом, содержанием и функциональностью интернет-магазина. Мощные маркетинговые инструменты, оптимизация для поисковых систем (SEO) и удобное управление каталогом товаров дают возможность создавать интернет-магазины с учетом уникальных потребностей вашего бизнеса. |
Так какова Ваша цена?
Если это цена где то в районе 2 варината - то стоит ли игра свеч? Ведь даже просто лицензиция битрикса 3 уровня стоит больше 300 000 руб.:D А что остаеться программистам на зарплату?:mad: Cтоимость создания сайта на CMS TYPO3 по данным CMS Magazine Средняя цена: 170 000 рублей До 50 000 1 От 50 000 до 100 000 1 От 100 000 до 200 000 1 От 200 000 до 300 000 1 От 300 000 до 500 000 1 От 500 000 до 700 000 Интересно посмотреть хоть один магазин хотя бы за 50 000 рублей на чистой typo3. А простой магазинчик - очень даже можно написать даже (второй раз оговорился не специально) самому! |
Ивано++
Благодарю за ответы, хотя немного и не о том всё :) Вы сами с какими готовыми магазинными экстами Typo3 работали? Ваши сентенции про Magento также не очень понятны: Цитата:
Дальше приводите данные CMS Magazine для сайтов на Typo3, хотя для магазинов там есть немного другая статистика цен. Про Битрикс - вообще чушь пишете :( Ознакомьтесь с прайсом сначала |
Ну что, давайте приступим.
Момент 1 - цена 300 000 руб. 3 уровень лиценции - что тут не понятного (смотрите видео битрикса о новой их версии 12+) Момент 2 - Магенто - это самостоятельная система и по большому счету - она не имеет отношения к typo3 Это как интеграция с phpbb - ключевое слово интеграция... У битрикса - их магазин - это одно целое. Момент 3 - Про врагов - говорю что никогда им не посоветую использовать готовые Ext-ы типа ecommerce... Я один раз попробовал это дело поставить - это застрелиться, сколько там настроек и ничего не работало после 3-ех дрей работы - в итоге плюнул... на это дело - - т.к. возможно Вы почетные гуру - а я в этом коммерце 0 (для меня этот показатель по трудозатратам не проходит фильтр) - да и потом - все эти эксты - не конкурентноспособны... Лучше выбрать готовое решение - аля битрикс/Magento - или еще что-то другое... Чем тема магазинов в typo3. Момент 4 - статистика цен взята с сайта данного форума http://www.typo3.ru/developers/ - т.что если там что-то не достоверное - уж извиняйте... Момент 5 - смысл обсуждать что и сколько я сделал не вижу - мы же здесь с Вами не размерами мериемся... (кроме typo3 и bitrix ничего не юзаю) я же Вас спрашиваю про цену - меня она интересует - какую бы вы мне цену заплатили, что бы я сделал для вас магазин с тем набором параметров которые выше перечислил - тоесть едакий шаблон как у битрикса "мебельный магазин". У Вас же почему-то есть именно интерес делать магазин на системе typo3 - меня вот это интересует - значит есть что-то что в других системах не устривает (ну кроме конешно покупки лицензции когда она съедает определенную часть бюджета проекта)... - простенький шаблон + система! Интересует целесообразность вложения средств в тему магазинов typo3... Или все-таки дешевле, да и удобней уже готовым пользоваться... Для меня это тоже очень больная тема - т.к. очень хочу уйти от всего другого и перейти на разрботку исключительно только на typo3. Т.к. по мне ни одна система не дает такого гибгого подхода в работе... |
Если кратко, то вот эта ваша фраза:
Цитата:
Пару лет назад делал магазин на tt_products, в принципе, хоть и не сразу, но все необходимые функции заработали. Правда пришлось мучать автора, но он оказался вполне отзывчивым товарищем. После этого все магазы делал на других магазинных движках (так получалось по разным причинам). Сейчас вот думаю вдруг появилось/обновилось что-нибудь из экстов принципиально другого уровня, чем тот же commerce. Раза три пришлось столкнуться с самописными "магазинами" для Typo3 - к сожалению ничего хорошего сказать про них не могу. Хотя один магазин был очень неплохо продуман и сделан. Но это всё были магазины, сделанные под конкретные требования заказчиков и не тиражируемые (не представленные в репозитарии). Про стоимость создания магазина - даже не стану предлагать какие-то цифры. Имхо всё очень индивидуально - или магазин, которые будет представлять собой минимальный набор функций, или универсальный, гибко-настраиваемый и скорее всего дюже запутанный магазин :( Это будут 2 абсолютно разных решения, каждое со своей ценой. Вкладываться в разработку магазина для Typo3 - вопрос интересный! Тот же tt_product имеет, например еще и платную версию, которая достаточно активно обновляется. А то, что выложено в репозитарии по ключу tt_products это старая версия, однако вполне работоспособная. Это я к тому, хотите ли просто разработать магазин на свои средства (или в свое свободное время) и выложить его в публичный доступ с соответствующей лицензией, например GNU. Или использовать ее исключительно в своих проектах (примерно так видимо и делает крупные студии, работающие на Typo3) |
Ладно раз такая пьесса пошла - меня даже больше волнует не сама проблема магазина - как уже говорил написать функционал магазина это дело реализуемое ---- больше затрагивает тема 1) универсальной категоризации данных - 2) универсальной юзабилити для менеджеров - согласитесь сейчас набивать и забивать формы в typo3 "девочкам модераторам" не очень-то удобно - и кол-во щелчков мышкой очень большое - до того момента как перейдешь к непосредственному редактирвоание 3) и универсального инструмента управления полями - Аля битрикс инфоблоки...
По магазину: у меня имеются небольшие наработки еще с демо сайта по интернет-магазину on typo3, а также есть один сайт где реализована корзина, оформление заказа и т.д. - а также очень солидный личный кабинет - но предпочту пока не публиковать этот сайт... - но развивать данный проект (магазина) готов, но после доведения до ума Платформы (т.к. магазин будет связан хотя бы с досками платформы)... После платформы готов заняться созданием загатовки магазина для typo3 (по аналогии Интернет-магазина мебели в битрикс)... Но интересует следующий момент - вот Вы говорите студии там чего-то разрабатывают - и типа они такие крутые парни и перцы - что у них все в шоколаде - у них есть какие-то там самописные расширение "звезды" которые они боятся выложить, а своих сотрудников-программеров заставляют подписывать документ о неразглашении тайны фирмы и иии... - а я уверен - что ничего подобного у них нет - что могло бы меня удивить.... - наверное единственное чем они меня могут удивить - это гирляндой слева из количества добавленных кнопочек, а также разноцветным дервом страниц с различными выбранными иконками по сраницам - вот и все... Поэтому - что предлагаю... Меня больше по жизни интересует не создание сайтов как таковых - а разработка к ним программных кодов - , решающих определенную задачу - моя мечта уйти от создания сайтов полностью. Помогите мне найти спонсоров на это дело, а также объясните как Ассоцация typo3 выделяет деньги на проекты и как это можно реализовать... И тогда у typo3 появится полноценный магазин-заготовка, даже с демо-сайтом... А главное это будет работать на универсальном инструменте управления данными (доски) с возможностью интеграции к примеру 1С... |
Цитата:
Цитата:
Это решается дашбордом и можно добавить ссылки в левое меню и возможно что-то типа http://typo3.org/extensions/reposito...recordsmanager использовать. Действительно серьезная проблема - это что не хватает функциональности у модуля List (фильтры, поиск). Ну и конечно специализированный интерфейс будет гораздо симпатичнее универсального. Цитата:
По-моему управление полями мало кому нужно. Разработчику для модулей средней сложности и простых - удобнее в кикстартере нарезаь таблицы и выводить через tesseract. А юзеру это вообще все равно. |
http://mocassino-planet.ru/
Делал на мультишоп - многое пришлось доделывает, сейчас магазин реально работает, ищется, обслуживается и т. п. Большое НО - это не совсем TYPO3, свой "внешний" модуль администрирования, не прописаны таблицы в TCA, просто так не разобраться и все такое... Из плюсов - быстрый (самописнаё кеширование), хорошо настраивается, при знании php. Вообще, не рекомендовал бы для новичков - внедрение порядка месяца, документация не на уровне. http://skladsistem.ru/ - каталог, самописный на основе news, возможность (пока не задействованная) корзины на wtcart и powermail. За последнее время ничего лучше не находил... Кто-то еще использует тессеракт с выводом из собственных таблиц, на мой взгляд, вариант не лучше, чем каталог на основе новостей. |
Да друзья, пожалуй констатирую, что ситуация не сильно изменилась за последние годы :(
Решения "из коробки" по-прежнему нет, а как бы хотелось что-нибудь похожего по функционалу, универсальности и уровню документации классических tt_news... |
Цитата:
Интеграцию 1с можно реализовать и сейчас - ничто не мешает взять данные из сторонних таблиц, их поменять и записать... Другое дело, это также лично мое мнение, - бухгалтерия отдельно, внешние данные - отдельно. Несмотря на привлекательность всеобъединения, деньги и реальные операции лучше держать отдельно... Модуль магазина как-то уже начинал, но не хватило времени - вообще, все реально, главное здесь хорошо продумать структуру данных. На данный момент, из существующего ничего хорошего не нашел. Подробнее в посте выше. Но многое из сделанного меня пока не устраивает. Что касается личного магазина - здесь у typo3 огромные преимущества. Можно задействовать что угодно из элементов, установив соответствующие права. Далее, с чем еще сталкивался - это отсутствие функций импорт/экспорт. В частности (в версии 4.x) много проблем возникает с картинками - typo3 нужно их переместить во временую папку... Все остальное решаемо - обычная запись/чтение полей таблиц. Для магазинов/каталогов это - очень важный фактор. Что касается удбности (юзабилити) работы с формами - это недоработки администратора-создателя сайта. Все "ненужные" поля нужно отключить, оставить лишь нужные. Здесь у typo3 очень большой запас прочности, кто бы что не говорил... Лень и желание. Рабочий процесс при этом можно выстроить как угодно. Вот как-то так... |
Появилась потребность вернуться к теме интернет-магазина.
Собственно вопрос в том, кто как производит наполнение своих каталогов магазина, и кто какие cms - использует... Ключевой вопрос - как Вы наполняете свои каталоги на сайтах - и какие процессы у Вас автоматизированы? Интересует опыт... |
Бухгалтерия - вещь классная.
У них есть База товаров - там содержится вся информация о таварах, заказах, остатках (количестве единиц) - так полагаю нормальный супер дрюпер пупер упер магазин заточен на подключение к бухгалтерии и дерет информацию из нее -- этот магазин как бы внешняя оболочка бухгалтерии в виде сайта? Так кто как заполняет магазины? В данную тему - возможно сам с сабой буду писать опыт собранный в интернет о магазина... |
Одного только не могу понять - вот у них есть набор полей...
А на сайтах обычно эти поля вручную создают под конкретную задачу - или есть еще и возможность их же "синхронизировать" с бухгалтерией? |
Таким образом - как полагаю - самая актуальная БД всегда содержится у Бухгалтерии в 1С?
|
Связывать бухгалтерию с интернет магазином я бы не стал. Причина простая - невозможно взломать и украсть то, что в принципе не связано с интернетом. Вообщем лучше делать выгрузку операций и проводить синхронизацию с базой данных. К тому же там какие-то сложности с 1с, насколько я знаю, в плане совместой работы с базой данных.
Что касается заполнения магазина - это уже смотря откуда сами исходные данные берутся, в каком виде они подготовлены. Так, в мультишоп, например, можно делать импорт/экспорт, для этого нужно сопоставить поля из источника (текстовый файл, csv...) и поля в таблице для товаров. Дело это муторное по-началу, но без этого, думаю нигде не обходится, но по отлаженному механизму работать можно. Другое дело, что продавцам вечно нужно что-то добавить/убрать/переделать... Еще одна сложность, как я уже говорил, работа с изображениями - нужно предварительно придумать схему их расположения и именования на сервере, загрузить при занесении в поля таблицы указывать правильные пути к изображениям. Если товаров немного, то и заполнять можно ручками... Видел и импорт в эксель, но, к сожалению, тут другая сложность - не работает с utf8... Вообщем то, чем я сталкивался пилить и пилить. Выгружать можно и в обычный текстовый формат или csv... Это сродни, кстати, модулю выгрузки товаров для яндекса - вообщем-то меняется лишь антураж представляемых данных. Что касается набора полей в базе данных, то действительно, для каждой задачи они сильно разнятся. Поэтому здесь все индивидуально. То же касается и каталогов - задачи схожи. Ну а что касается разработки магазина, то вот полезная книжица: PHP 5 E-commerce Development |
У меня очень мало опыта (да чего греха таит на typo3 - его вообще нет - читать жирным) в создании магазинов - завязанных именно на обмен данными с бухгалтерией.
Но проблема вот в чем - магазин сегодня продает товар, у него меняется участие в акции - и все это должно работать синхронно... Поэтому и спрашиваю - есть ли у кого-то опыт создания именно сайта-магазина на основе данных бухгалтерии - где сайт по существу выступает как оболочка бухгалтерии, где она является ядром... Поделитесь еще опытом. А за книжечку спасибо... Поизучаем... |
Насчет тесной связи с бухгалтерией не скажу. Скажем моя жена все ведет отдельно, то есть магазин не является "витриной" бухгалтерии. Причины я озвучил.
На мой взгляд, чтобы этого добиться, нужно "связать" данные, выгружаемые из бухгалтерии с данными в таблицах на сайте. То есть изначально спланировать отображение таблиц друг к другу. А затем выгружать-загружать... Для получения данных из внешних источников имеются расширения, либо нужен модуль импорт/экспорт. Ну а далее - связь в реальном времени врядли реализуема, так как при этом нужно постоянно запрашивать стороннюю базу данных об изменениях, вносить изменения и так далее. То есть это модуль синхронизации данных. И при его постоянном задействовании ни о каком кешировании, на мой взгляд, не может быть и речи. Целесообразно проводить синхронизацию в какое-то определенное время. Далее, что касается акций/купонов/массового снижения цен - это все модули самого магазина и их конкретная реализация отличается. Что при этом должен уметь магазин - обозначать товары для участия в акции, уметь учитывать коды купонов при оформлении заказа и т.п. К тому же должна быть предусмотрена возможность массового изменения цена на выбранные товары. Из опыта работы с TYPO3 подобных магазинов с удобным управлением нет. Сам я в свое время выбрал Мультишоп, можете присмотреться к нему. Но это не вполне TYPO3 решение, так как по существу система в системе. Скорее набор PHP скриптов для выполнения определенных операций. Таблицы там также не обозначены для TCA, поэтому подобраться к данным из них из TYPO3 сложно, приходится работать как со сторонними таблицами. Но тем не менее, магазин сделать вполне реально. Кроме того, там имеется свое решение по кешированию через файлы, почта также работает на "внутреннем" механизме ну и так далее - это дает неплохую производительность, так как в TYPO3 много ресурсов расходуется на "согласование" данных в таблицах (видны/не видны, разрешены/не разрешены и т.д.). Имеется механизм импорта/экспорта - но с оговорками по экспорту в эксель - все нечитаемо, так как неверная кодировка, и исправить я тогда это не смог. Ну и работает все это из своего внешнего интерфейса, практически никак не связанного с TYPO3. Вот как-то так... Либо переходить и выбирать специально созданные CMS для магазинов, с модулем работы с 1С и другими приблудами. |
И все таки приходится сново возвратиться к данной теме...
А что собственно должен уметь делать магазин в панели администрирования на Ваш взгляд - какой там должен быть функционал - что бы это считать полноценным магазином - интересует Ваш опыт (там интеграция, импорт, экспорт, статистика чего?)... Внешнюю работу не рассматриваем (формы заказа, регистрация, корзина, список товаров на сайте, фильтр и прочее) - хотя на Ваше умотрение - но думаю что это мало интересно, т.к. это видно и так на любом добротно сделанном магазине... Актуальность темы вызвана тем, что пересмотрел опять же не мало 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 код:
Да еще и эта недопирамида MM. Hidden, deleted да limit - и этого достаточно выше крыши... Ну или конечно если хостинг позволяет - то это другое дело... Поэтому чем проще запросы тем лучше... А время на for и foreach - это неизбежное... Ведь на сколько мне известно mysql - это теже файлы (только два - одни структура, другой данные). Вот представим мы делаем просто запрос к файлу casche.temp - он у нас выполнится за минимум милисекунд. А если нам еще надо разобрать данные полученные из него, да еще что-то запросить и присоединить из файла casche2.temp... Что через БД, что через файловые системы - раздницы никакой не будет... |
Симпла пока еще довольно сырая и дорожает от версии к версии. CS-Cart умеет гораздо больше и лучше за те же деньги.
|
Цитата:
Тоже интересная штука - но в нем как мне показалось больше лишнего... |
Ага, самое ненужное это, конечно, обработка картинок категорий, чего добиться от Симплы в принципе пока не получается не дописав чего-то своего.
|
И еще , прокручивая в голове всевозможные варинты развития событий . остаюсь "неопределенным" по поводу того, как хранить данные.
По идее хранение товаров можно организовать в виде одной таблицы, где в данной можно создать 1 поле (аналог doktype для pages, CType для tt_content) - и мы сможем создавать в рамках одной таблицы разные товары с разным набором свойств.... Так обычно и делают. Но вот у меня есть один момент, который в голове не совсем укладывается. К примеру как совместить товары с категориями. Или к примеру, у нас будет еще какая-то 3-тья таблица.... В которой мы будетм хранить к примеру город (или еще что-то)... Получается что весь магазин (экспорт, импорт) будет завязан на значения всех таблиц, которые мы будем желать использовать... Но вопрос в том, будут ли у бухгалтерии данные таблицы - и как они к примеру хранять то, к какой категории принадлежит товар? |
Естественно при экспорте/импорте обрабатывать придется все таблицы. К тому же, таблиц там много...
Товар, свойства товара, набор параметров для свойств товара, категория товара. К тому же, нужно отразить влияние каждого параметра из свойств на конечную цену (например галоши разного размера будут стоить по разному). Легче все это проследить на моделях данных уже существующих магазинов, иначе что-то да упустишь. А уж как это отражается в бухгалтерских программах - конечно лучше узнать у бухгалтеров, работающих с интернет магазинами. |
И снова к данном теме - как к теплому месту.
Собственно есть два вопроса 1. У typo3 - есть какой-то TASK sentr - т.е. как понимаю это центр задач. У многих CMS смотрю есть похожие вещи - в т.ч. синхронизация с БД 1с. Собственно вопрос - как эти процессы могут происходить если нет обращений к сайту. Ведь данные скрипты по идее все равно должен запускать пользователь - посещяя определенную страницу либо кликая кнопку в панели администирования. Ведь у PHp-нет никаких функций, которые бы позволили установить комманду на автовыполнение, например в 23:00 - выполнить такой-то скрипт... Ведь это возможно только в настройках хостинга (например рез.копирование - 1 раз в день Как это вообще может работать в CMS??? которые написаны на PHP? 2. И опять к теме 1С - как в 1С хранятся товары и какая структура-то выгружается на сайт... Ведь я же правильно понимаю что в 1С - хранится только минимум о товарах (а именно цена, остаток, а вот поля свойст, картинки - здесь все это не храниться, а уже забивается на сайте? или как... И получается что когда делается интеграция с 1с - то обновляются только поля товаров - цена, количество... Или как это? |
1. Работает через задачи cron и установку соответствующей задачи в планировщике (что не отменяет настройку, соответственно, сервера на проверку установленных в планировщике задач).
2. Фиг его знает, но 1С - та же база данных, а уж все ее "надстройки" - это как раз взаимодействия полей в базе данных - данные берутся из справочников и определенным образом взаимодействуют, а выводятся через соответствующим образом настроенные формы. А для выгрузки существуют какие-то стандартные структуры - вот на это и надо обратить внимание, ведь это, как я понимаю, какие-то стандарты бухгалтерских программ (1С при этом не самая лучшая, просто "народная", "попсовая"). |
Цитата:
И так понимаю - что это команда хостингу... |
Цитата:
Теперь очень хорошо понимаю - что есть супер проект за 10 000-30 000 руб (за 5-7 дней) и что есть серьезный проект (2-3 месяца работы) http://habrahabr.ru/post/137888/ http://www.webbix.ru/studio/case/detail.php?ID=1895 http://www.webbix.ru/studio/1c/ |
Да, занятно...
|
Сталкивая с различными проектами - по поводу каталогов - нахожу интересные вещи - а именно:
1) кто то делает каталог магазина на дереве страниц + добавляют поля для страницы необходимые + дописывают 3-4 модуля pi (обычно это сам каталог, фильтр и ряд других модулей) 2) либо кто-то делает это совсем на отдельных таблицах с новым модулем - который строит дерево... Т.е. примерно также как это идет в битрик - все на одтельных инфоблоках. Какими Вам видятся глобальные плюсы и минусы у двух различных подходов? Единственных минус вижу по первому варианту - это то, а) что сам каталог мешается с деревом страниц - и по этой причине будет сложнее делать экспорт/импорт... И кстати при таком варианте наверное лучше сделать специальный тип страницы - т.к. не на каждой же странице вставлять плагин Каталога - и это надо автоматизировать! Единственный минус вижу по второму варианту - это то, что на отдельные ветки каталога - нельзя дать доступ на редактирование отдельной ветки через модуль "Доступ" - ведь это также как с деревом tt_news... (НО - в принципе и здесь Вы можете опять же хранилище разбивать на сколько угодно папок... и к ним давать доступ - к примеру по прендам.... И еще что интересно (уже не первый раз) - когда делают каталоги на typo3 - то не особо "заморачиваются" по поводу двух наиболее интересных полей - а именно "Общие характеристики" и "Доп.характеристики" их - обычно не разбивают на поля а делают bodytext-ом... Более других вариантов создания каталогов - не находил. |
Третий вариант - на отдельных таблицах с существующим модулем - новости тому пример.
Дополняем новости лишь нужными характеристиками, хранящимися в отдельных таблицах и делаем шаблон для их вывода. Остальным занимается движок самих новостей (на самом деле все сложнее). Но вкратце - так. |
Цитата:
|
не подходил так к вопросу, но...
Права даются на страницы в том числе. Так что записи, относящиеся к страницам, к которым нет доступа и не должны быть видны. Вообще, во всем требуется опыт. Да и вообще, какие предложения? Пока вижу размышления ни-о-чем. |
А я напомню, что изначально создавал эту тему, чтобы понять какие готовые решения для магазинов в настоящий момент актуальны. Но по обилию сообщений и по их содержанию понимаю, что "чифырнуть бы ништяк, да голяк..." :)
Не придумали еще бесплатного магазинного движка для TYPO3 |
|
| Часовой пояс GMT +4, время: 14:23. |
Работает на vBulletin® версия 3.8.1.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot