trdm писал(а) 19. Декабря 2010 :: 14:32:

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

>Вся «программа» (описание экранов, отчеты, модули) хранится в БД.

Меня смущает терминология в твоем проекте. Напрмиер "экраны". Почему не "формы"?
Мне кажется хранить конфигурацию ("описание экранов, отчеты, модули") удобнее хранить в файловой системе - легко что-нибудь ручками подправить, скопировать.

blindvic писал(а) 19. Декабря 2010 :: 16:59:


мне терминология тоже не нравится писал первое пришедшее на ум, не до того было
может "форма" и лучше звучит, можно поменять

если хранить в файловой системе - будут проблемы с распространением. А так у меня вся "конфигурация" в одном файле SQLITE - все в одном. Легко будет делать обновление у клиента.
Что касается руками подправить... - так и в БД тоже можно подправить. А для исправления на лету я еще собираюсь сделать вызов определенных модулей, что бы не трогая "конфигурацию" можно было донастраивать мелочи у клиента.

Еще + : описание храню в таблицах и могу (и использую) эту инфу для контроля целостности БД. Т.е. если какое-то поле таблицы БД привязано к справочнику, то при попытке удаления из этого справочника я проверяю, не используется ли эта строка в где-нибудь. Чтото типа FOREIGN KEY на уровне приложения. А если конфигурация=набор_файлов , то такую фишку не реализуешь

Про Цитата:

что имеется в виду? У меня описываются "формы", на их основании создаются таблицы в БД, формы сами при загрузке привязываются в меню. Как тут дерево использовать? Хватает просто системы меню пока

Цитата:

а чем предопределенная процедура лучше, чем отличается от вкладки для ее написания? и в чем эта визуализация состоит в этом случае?

villager писал(а) 19. Декабря 2010 :: 17:54:
У тебя код, выполняемый при наступлении определенный событий, разбросан по вкладкам.
В 1С этот код является частью модуля - функции с предопределенными именами.
http://www.mista.ru/tutor_1c/predopred_proc.htm

trdm писал(а) 20. Декабря 2010 :: 11:20:

я не против.
К тому, что код по полкам разложен привык еще в Foxpro - сложно отвыкать
С другой стороны - к событиям привязываю конкретный код, поэтому собирать форму проще из кусков.

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

а повторно используемый код в модулях хранить можно: грузи и используй

кстати,  еще довод, зачем хранить конфигурацию в БД: защита от несанкционированного доступа

В целом впечатления хорошие.
Хотя Питон не знаю.
А на Шарп с Явой, тоже, наверно, аллергия.
Ролик показывает, что инструментарий, скорей всего, достаточен для like1C.
Важно проектирование системы, концепция, фундамент.
А как формы рисовать разберёмся, проектирование или подбор инструментария и удобство работы программиста, я думаю, не столь важно.
Идея важнее, фундамент.