Vers: Брррр, при чем тут мониторинг цен конкурентов? Нам магазины присылают своих поставщиков и их остатки, мы их обрабатываем, своидм к единой номенклатуре за счет машинного обучения а не "по некоторым признакам с некоторой вероятностью" и через API импортируем на сайт ИМ в нормальном универсальном виде! В каком месте это не имеет никакого отношения к импорту?
Идентификация может быть либо по некоторому уникальному коду (SKU или артикул по-русски) либо ко другим, но неоднозначным признакам. Ваше "машинное обучение" и есть распознавание по неоднозначным признакам (я экспертными системами занимался в середине 90-х). Вам это нужно чтобы свести несколько прайсов с идентичными товарами от разных поставщиков к единому. Такое используется в том числе при мониторинге цен конкурентов. А ТС вообще не говорил об услуга, он говорил о софте, автоматизирующем импорт. Это вы начали не в тему рекламу своих услуг.
Никто не говорит об существенной универсальности. Речь о т.н. БАЗОВОМ функционале.
Мне несказанно непонятно, почему вместо исправления БАЗОВОГО функционала люди "фигачат рюшечки". Тут даже дискуссии быть не может о том, что является базовым, а что небазовым, он уже есть зачастую в движке, но работает криво.
Если же говорить о том, что является или не является базовым функционалом, то тут у меня тоже "больше вопросов, чем ответов". Я там сверху некоторые из особо "фееричных" примеров приводил.
ЗЫ. Странно что с темы "описанный АПИ для импорта" бодро срулили в тему какого-то никому не нужного "универсального импорта, каких-то агрегаторов прайсов итп".
Да все в движках есть, просто вам это не нравится. Вы по сути утверждаете, что именно ваши требования к функционалу движка ИМ являются главными :-). Но это не так :-). Огромное количество людей считает например тот же Opencart вполне нормальным движком и без API импорта. Потому что им это не надо :-). И их много и их требования тоже главные :-).
med--brat: Вставлю свои 5 копеек.
По поводу импорта/экспорта - несостоятельный спор, потому как эта задача как раз и должна относиться к "допиливанию движка под собственные нужды". Потому что здесь очень много факторов: структура каталога на стороне ИМ, на стороне поставщика, на стороне учетной системы (1с, к примеру). Это как минимум.
Кстати, по раз уж речь зашла за 1С: как по мне, очень умную политику они проводят. Есть ядро (1с7, 1с8.1, 1с8.2) со своими специализированными объектами и функциями (справочники, константы, журналы, документы, пользователи и так далее), а есть конфигурации (то, что навешивается на ядро). Конфигурации пишутся под конкретный вид деятельности (бухгалтерия, производство, управление продажами, ресторан, сто и так далее). Но даже под эти узкоспециализированные конфигурации очень много дописывают своего (то же управление производством - монструозная разработка от 1с, но ее еще в клиента "пилят и пилят").
Теперь сравним рынок cms для торговли. В основном, это ядро (бывает похуже и получше), но мало кто делает узкоспециализированных вещей. То, что я знаю (навскидку) - это магазин автозапчастей. Почему бы не сделать на ядре надстройку магазина Одежды, магазин стройматериалов, магазин электроники?
Но нет, пилят и пилят только само ядро cms, чтобы оно было суперуниверсальным и чтобы из него потом надо было "выпиливать и выкидывать" некоторые ненужные вещи (вот не поверите, но некоторым не надо те же атрибуты к товару, а в движках они уже прикручены намертво, и в каждом запросе внутри движка идет проверка "А нету ли в этого товара из 100500 таких же товаров атрибута?".)
Печалька.
Именно. У разработчиков CMS, в том числе и для ИМ, два варианта:
- написать суперуниверсальный движок, который кликанием чекбоксов в админке можно настроить чуть ли под любые нужды
- сделать не CMS а CMF, которую допиливать будет удобнее.
К первому типу относятся например Prestashop и Drupal. Результат - оба превратились в монстров, с которыми стало невозможно работать. Вырезать запаришься все лишнее.
Ко второму типу из ИМ - Magento, из движков общего назначения - Pimcore, Yii, Django и т.п. Ну или совсем что-то типа Dvelum (вебовская среда разработки). Нужны весьма квалифицированные подрядчики для создания и поддержки ИМ.
В обоих случаях разработчики стремятся к универсальности, чтобы повысить охват рынка. И эта же высокая универсальность является наибольшей проблемой.
SeVlad: Так же как, смазка замка в двери к типу двигателя :) Конечно, мне такого не понять.
Короче, как я вижу, ни аргументов ни нормальных объяснений нет. Очередной трёп и набивание себе цены. Ок, с этим всё ясно.
Молодец, уважаю самокритичных :-).
---------- Добавлено 28.07.2014 в 18:21 ----------
_SP_: Это не отвечает на вопрос, почему "народившиеся" такие-же убогие...
Новые как-бы проекты.
Или они все форкаются ?
Ну во первых конечно форкаются. Так на основе opencart делают сборки ocStore и MaxiStore. Ну и соответственно обе ..., такие же как и основа. А что еще ожидать когда отстойный продукт пытается усовершенствовать кустарь одиночка (только заплат наляпать в виде бесплатных модулей).
Во-вторых чтобы написать качественный продукт нужно не только много денег, но и правильная организация управления проектом. А таких спецов вообще не много, а на постсоветстком пространстве вообще раз-два и обчелся. Ну конечно же работа таких спецов дорого стоит, а значит опять все упирается в деньги и очень большие.
Достаточно посмотреть, сколько вложено в разработку Мадженто. Какие монстры финансируют ее разработку (eBay).
SeVlad: Примеры сложностей в большинстве случаев. "Не плоских" данных если угодно. Для того, что бы можно было увидеть масштаб проблемы.
Где?!
По сложности данных - войдите в любой магазин и посмотрите, есть ли там фильтрация по параметрам например. А вообще такое применимо к подавляющему большинству товаров (технические изделия, одежда, обувь, табачные изделия, продукты, да все что угодно) в магазинах с номенклатурой от 1000 артикулов и выше. Любая фильтрация по свойствам требует специальной организации данных об этих свойствах. И делается это уже не в плоских таблицах в основном (не считая мадженто). Проблемы заливки в такие структкуры я приводил чуть ранее для Magento, opencart, Prestashop.
Хотите узнать как это работает, возьмите любой движок и попробуйте в нем настроить фильтрацию товаров по параметрам. Хоть тот же опенкарт с демонстрационной базой. И все поймете сразу.
Примеры чего? Да и собственно говоря зачем они вам? Пока на личном опыте не попробуете, все равно не поймете о чем речь идет. Да и примеры я приводил ранее.
SeVlad: Я никогда не говорил об абсолютной универсальности. Я все время подчеркивал - для большинства (чит: популярных) задач. И это реально. И ессно, что абсолютной универсальности быть не может.
"Структура ВП" тут никаким боком. Речь о соответствии полей (артикул цена, описание и тд) импортируемых данных и полями "принимаемой стороны". ВП был приведён просто как хорошо известный мне образец реальной реализации.
Как раз для большинства задач универсального решения и нет. Имеющиеся средства применимы в лучшем случае для каждой 10-задачи, то есть закрывает 10, а не 90%.
Вордпрес как раз причем. Вы делаете свои утверждения исходя из того, что данные из ячеек исходной структуры нужно просто положить в ячейки целевой. Но во-первых это легко если имеет дело с двумя плоскими таблицами (а в большинстве случаев это не так), во-вторых, что исходные данные укладываются в целевую структуру без промежуточной обработки, а это в большинстве случаев тоже не так. Собственно именно поэтому нет универсального средства до сих пор, и вот почему ваши утверждения ошибочны (вы строите их на ошибочных представлениях о процессе импорта данных для ИМ).
Брррр, при чем тут мониторинг цен конкурентов? Нам магазины присылают своих поставщиков и их остатки, мы их обрабатываем, своидм к единой номенклатуре за счет машинного обучения а не "по некоторым признакам с некоторой вероятностью" и через API импортируем на сайт ИМ в нормальном универсальном виде! В каком месте это не имеет никакого отношения к импорту?
Идентификация может быть либо по некоторому уникальному коду (SKU или артикул по-русски) либо ко другим, но неоднозначным признакам. Ваше "машинное обучение" и есть распознавание по неоднозначным признакам (я экспертными системами занимался в середине 90-х). Вам это нужно чтобы свести несколько прайсов с идентичными товарами от разных поставщиков к единому. Такое используется в том числе при мониторинге цен конкурентов. А ТС вообще не говорил об услуга, он говорил о софте, автоматизирующем импорт. Это вы начали не в тему рекламу своих услуг.
Никто не говорит об существенной универсальности. Речь о т.н. БАЗОВОМ функционале.
Мне несказанно непонятно, почему вместо исправления БАЗОВОГО функционала люди
"фигачат рюшечки". Тут даже дискуссии быть не может о том, что является базовым,
а что небазовым, он уже есть зачастую в движке, но работает криво.
Если же говорить о том, что является или не является базовым функционалом, то тут
у меня тоже "больше вопросов, чем ответов". Я там сверху некоторые из особо "фееричных"
примеров приводил.
ЗЫ. Странно что с темы "описанный АПИ для импорта" бодро срулили в тему какого-то
никому не нужного "универсального импорта, каких-то агрегаторов прайсов итп".
Да все в движках есть, просто вам это не нравится. Вы по сути утверждаете, что именно ваши требования к функционалу движка ИМ являются главными :-). Но это не так :-). Огромное количество людей считает например тот же Opencart вполне нормальным движком и без API импорта. Потому что им это не надо :-). И их много и их требования тоже главные :-).
Вставлю свои 5 копеек.
По поводу импорта/экспорта - несостоятельный спор, потому как эта задача как раз и должна относиться к "допиливанию движка под собственные нужды". Потому что здесь очень много факторов: структура каталога на стороне ИМ, на стороне поставщика, на стороне учетной системы (1с, к примеру). Это как минимум.
Кстати, по раз уж речь зашла за 1С: как по мне, очень умную политику они проводят. Есть ядро (1с7, 1с8.1, 1с8.2) со своими специализированными объектами и функциями (справочники, константы, журналы, документы, пользователи и так далее), а есть конфигурации (то, что навешивается на ядро). Конфигурации пишутся под конкретный вид деятельности (бухгалтерия, производство, управление продажами, ресторан, сто и так далее). Но даже под эти узкоспециализированные конфигурации очень много дописывают своего (то же управление производством - монструозная разработка от 1с, но ее еще в клиента "пилят и пилят").
Теперь сравним рынок cms для торговли. В основном, это ядро (бывает похуже и получше), но мало кто делает узкоспециализированных вещей. То, что я знаю (навскидку) - это магазин автозапчастей. Почему бы не сделать на ядре надстройку магазина Одежды, магазин стройматериалов, магазин электроники?
Но нет, пилят и пилят только само ядро cms, чтобы оно было суперуниверсальным и чтобы из него потом надо было "выпиливать и выкидывать" некоторые ненужные вещи (вот не поверите, но некоторым не надо те же атрибуты к товару, а в движках они уже прикручены намертво, и в каждом запросе внутри движка идет проверка "А нету ли в этого товара из 100500 таких же товаров атрибута?".)
Печалька.
Именно. У разработчиков CMS, в том числе и для ИМ, два варианта:
- написать суперуниверсальный движок, который кликанием чекбоксов в админке можно настроить чуть ли под любые нужды
- сделать не CMS а CMF, которую допиливать будет удобнее.
К первому типу относятся например Prestashop и Drupal. Результат - оба превратились в монстров, с которыми стало невозможно работать. Вырезать запаришься все лишнее.
Ко второму типу из ИМ - Magento, из движков общего назначения - Pimcore, Yii, Django и т.п. Ну или совсем что-то типа Dvelum (вебовская среда разработки). Нужны весьма квалифицированные подрядчики для создания и поддержки ИМ.
В обоих случаях разработчики стремятся к универсальности, чтобы повысить охват рынка. И эта же высокая универсальность является наибольшей проблемой.
А не уважаю балаболок. Как бы сильно они не расставляли пальцы.
Как вам видимо должно быть противно смотреться в зеркало по утрам :-D.
Так же как, смазка замка в двери к типу двигателя :) Конечно, мне такого не понять.
Короче, как я вижу, ни аргументов ни нормальных объяснений нет. Очередной трёп и набивание себе цены. Ок, с этим всё ясно.
Молодец, уважаю самокритичных :-).
---------- Добавлено 28.07.2014 в 18:21 ----------
Это не отвечает на вопрос, почему "народившиеся" такие-же убогие...
Новые как-бы проекты.
Или они все форкаются ?
Ну во первых конечно форкаются. Так на основе opencart делают сборки ocStore и MaxiStore. Ну и соответственно обе ..., такие же как и основа. А что еще ожидать когда отстойный продукт пытается усовершенствовать кустарь одиночка (только заплат наляпать в виде бесплатных модулей).
Во-вторых чтобы написать качественный продукт нужно не только много денег, но и правильная организация управления проектом. А таких спецов вообще не много, а на постсоветстком пространстве вообще раз-два и обчелся. Ну конечно же работа таких спецов дорого стоит, а значит опять все упирается в деньги и очень большие.
Достаточно посмотреть, сколько вложено в разработку Мадженто. Какие монстры финансируют ее разработку (eBay).
А фильтрация никакого отношения к обсуждаемой проблеме (универсальности импорта) не имеет.
Имеет просто тебе этого не понять :-).
---------- Добавлено 28.07.2014 в 17:51 ----------
нет там ни какой сложности, только зашаблонизированность разработчиков ;)
Ну для того кто ее не может или не хочет видеть, действительно нет. Не признавать же свое незнание в самом деле :-).
это говорит только о кривости данных систем и больше ни о чём
Или о том, что вы не хотите видеть объективную сложность задачи, стараетесь упростить ее под себя :-).
Примеры сложностей в большинстве случаев. "Не плоских" данных если угодно. Для того, что бы можно было увидеть масштаб проблемы.
Где?!
По сложности данных - войдите в любой магазин и посмотрите, есть ли там фильтрация по параметрам например. А вообще такое применимо к подавляющему большинству товаров (технические изделия, одежда, обувь, табачные изделия, продукты, да все что угодно) в магазинах с номенклатурой от 1000 артикулов и выше. Любая фильтрация по свойствам требует специальной организации данных об этих свойствах. И делается это уже не в плоских таблицах в основном (не считая мадженто). Проблемы заливки в такие структкуры я приводил чуть ранее для Magento, opencart, Prestashop.
Хотите узнать как это работает, возьмите любой движок и попробуйте в нем настроить фильтрацию товаров по параметрам. Хоть тот же опенкарт с демонстрационной базой. И все поймете сразу.
Примеры когда будут?
Примеры чего? Да и собственно говоря зачем они вам? Пока на личном опыте не попробуете, все равно не поймете о чем речь идет. Да и примеры я приводил ранее.
Я никогда не говорил об абсолютной универсальности. Я все время подчеркивал - для большинства (чит: популярных) задач. И это реально.
И ессно, что абсолютной универсальности быть не может.
"Структура ВП" тут никаким боком. Речь о соответствии полей (артикул цена, описание и тд) импортируемых данных и полями "принимаемой стороны". ВП был приведён просто как хорошо известный мне образец реальной реализации.
Как раз для большинства задач универсального решения и нет. Имеющиеся средства применимы в лучшем случае для каждой 10-задачи, то есть закрывает 10, а не 90%.
Вордпрес как раз причем. Вы делаете свои утверждения исходя из того, что данные из ячеек исходной структуры нужно просто положить в ячейки целевой. Но во-первых это легко если имеет дело с двумя плоскими таблицами (а в большинстве случаев это не так), во-вторых, что исходные данные укладываются в целевую структуру без промежуточной обработки, а это в большинстве случаев тоже не так. Собственно именно поэтому нет универсального средства до сих пор, и вот почему ваши утверждения ошибочны (вы строите их на ошибочных представлениях о процессе импорта данных для ИМ).