Страница 2 из 2

Два DCT или как?

Добавлено: 15 Февраль 2016, 20:23
gopstop2007
finsoftrz писал(а):А зачем какие-то структуры использовать? Обмен с интернет-магазином обычно делается через csv или xml файлы. На крайний случай, если нужно буферизировать, можно использовать обычные локальные или app-шные очереди. Для своих интернетовских модулей я предпочитаю сразу создавать sqlite файлы в том виде, как они используются в вебе. Но это если все в своих руках - во много раз быстрее и проще...
Механизм который использую я, данные напрямую скидываются в БД инет магазина + плюс фото, Ваш, если я правильно понял, состоит из шагов:
1. экспорт данных программы в файл ( csv, xml) F
2. импорт файла F через админку интернет магазина. + фото
3 синхронизация всего этого, что удалить, что добавить, изменить и прочее...
мой:
1. экспорт данных в инет. магазин нажатием одной кнопки , при этом происходить полная синхронизация данных + фото
Что проще? Если я не прав - поправьте :cat:

Два DCT или как?

Добавлено: 15 Февраль 2016, 20:30
gopstop2007
RaFaeL писал(а):P.S. Я бы не рекомендовал делать приложения С1 - С10. Лучше сделать одно, а внутри кейсы
RaFaeL писал(а):Ну так, в глобал ембедс пишешь структуру FILE
Если руками сразу описать сложно, то сначала делаешь описание в dct, генерируешь приложение, лезешь в основной clw что он тебе нагенерил, копируешь оттуда описание файла Вот тут вставки, каждая условно для одного из "интернет-магазинов", в dct этих файлов нет, используются только в этой dll
вы сами себе не противоречите насчет кейсов или для каждого инет магазина создавать описания файлов и все это в глобале?

Два DCT или как?

Добавлено: 15 Февраль 2016, 20:36
gopstop2007
Губин Игорь писал(а):Если я правильно понял проблему, то вынеси весь интерфейс к БД магазина в отдельный DLL с неким универсальным "АПИ".Тогда адаптация будет заключаться в написании очередной прокладки, без изменения самой основной задачи.
В идеале да, но реально ли это? Описание структур файлов инет магазина в тхт файле + команды для курсоров там же :)

Два DCT или как?

Добавлено: 15 Февраль 2016, 21:37
finsoftrz
gopstop2007 писал(а):
finsoftrz писал(а):А зачем какие-то структуры использовать? Обмен с интернет-магазином обычно делается через csv или xml файлы. На крайний случай, если нужно буферизировать, можно использовать обычные локальные или app-шные очереди. Для своих интернетовских модулей я предпочитаю сразу создавать sqlite файлы в том виде, как они используются в вебе. Но это если все в своих руках - во много раз быстрее и проще...
Механизм который использую я, данные напрямую скидываются в БД инет магазина + плюс фото, Ваш, если я правильно понял, состоит из шагов:
1. экспорт данных программы в файл ( csv, xml) F
2. импорт файла F через админку интернет магазина. + фото
3 синхронизация всего этого, что удалить, что добавить, изменить и прочее...
мой:
1. экспорт данных в инет. магазин нажатием одной кнопки , при этом происходить полная синхронизация данных + фото
Что проще? Если я не прав - поправьте :cat:
Поправляю :-)
Если речь конкретно про меня, то я создаю весь контент интернет магазина автоматически из учетной системы и заливаю на хостинг. База данных в sqlite сразу в готовом для использования виде. Можно кнопку нажать, обычно ночью по расписанию на автомате. Ничего проще и быстрее не придумаешь.
Одно но - магазин должен быть свой и полностью контролироваться.
Если магазин чужой, то там обычно выгружается csv/xml, на хостинге загружается. Обычно на автомате. Или нажать две кнопки :-)
Напрямую писать в базу данных магазина - тоже когда-то предлагали. Но для этого надо, чтобы те, кто поддерживает магазин, разрешили такой доступ. При этом совсем не обязательно декларировать структуры в словаре - можно работать прямыми sql-запросами. Вариантов несколько, но про это лучше специалисты по sql расскажут, это не моя тема.

Два DCT или как?

Добавлено: 16 Февраль 2016, 13:28
RaFaeL
gopstop2007 писал(а): вы сами себе не противоречите насчет кейсов или для каждого инет магазина создавать описания файлов и все это в глобале?
А в чем противоречие?
Описание файлов в глобале, так как код разделен на несколько процедур, где все эти файлы используются... там разные режимы, ручной, автоматический и т.п.
Сами по себе описания файлов ничем особо не мешают, можно их хоть 100500 штук для всех инет-магазинов написать
А дальше я не знаю какая у вас логика, но вот допустим задача - выгрузить в инет-магаз справочник товаров, ну или прайс-лист. Чтобы не писать этот код 10 раз в 10 приложениях, напишите основную часть один раз, т.е. цикл по справочнику товаров, необходимые выборки, и когда нужна непосредственно запись в файл то делаете процедуру типа ExportPrice(Magaz_,NumT_,NameT_,.........) где Magaz_ это magic number нужного вам инет-магаза, а внутри процедуры
execute Magaz_
do ExportPriceYandexRu
do ExportPriceMailRu
...
end

и вот там внутри уже идет запись в структуру нужного инет-магаза. Этого уникального кода будет мало, и каждый следующий инет-магаз будете добавлять всё быстрее. Можно не делить на рутины, сделать все в одном месте, но громоздко получается. Еще нужны такие же процедуры вида открыть файлы - закрыть файлы

У нас когда то было во так же штук 10 разных приложений, в каждой свой словарь. Потом устали синхронизировать и сделали одно приложение. Потом устали его отдельно собирать и сделали dll в которой было соответственно 10 процедур. Потом мне надоело при добавлении каждой новой чужой базы писать один и тот же код и я сделал одну большую толстую процедуру с кейсами. Потом потребовался тихий режим и я ее разделил на несколько сурсников. Еще очень ускорил разработку переход с описания файлов на DynaLib но я не знаю, есть ли версии для С10, что-то давно сайт не обновлялся, мы для 6.3 в свое время приобрели, там отлично работает

Два DCT или как?

Добавлено: 17 Февраль 2016, 15:31
gopstop2007
Спасибо за толковые разъяснения
RaFaeL писал(а):Потом устали синхронизировать и сделали одно приложение.
я как раз на данном этапе :)

Два DCT или как?

Добавлено: 17 Февраль 2016, 16:54
Ал
Можно не делить на рутины, сделать все в одном месте, но громоздко получается.
пока не упрется в суммарный размер "кадра"... - потом будет вынужден делить