Читал.

С метаданными я б делал не так.

Мой вариат:
1. Все метаданные - пользовательские классы (классы написаные в конфигураторе на встроенном языке)
соответственно каждый класс должен реализовывать метод хранения, изменения, модификации структуры , отображению данных, добавление форм, тестирование данных....
таким образом кому какие метаданные нужны тот такие и рисует + разработка классов и метаданных - фактически одно и тоже.
2. Все классы (метаданные) хранятся в БД вместе с данными

Phoenix писал(а) 16. Января 2008 :: 07:13:


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

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

Про реквизиты не понял - для всех методанных одна таблица реквизитов?

Цитата:


насчет модулей не совсем так.

Таблица - BlobData
используется для хранения модулей, форм, описаний, печатных форм и прочей подобной информации
Поля:
ID - (INT) - Уникальный идентификатор записи
Identifire - (text) - Наименование объекта
IsMain - (INT) - Признак главной формы
TypeID  - (INT) - Тип данных владелец
KindID - (INT) - Вид метаданных
SubKindID - (INT) - Владелец внтуренний (например форма владелец текущего модуля)
ValueType - (INT) - Тип информации, 0-Форма. 1 - модуль, 2 - таблица. 3 модуль объекта, 4 - описание ...
Value - (blob) - Значение
DateTimeLastUpdate - (datetime) - Дата время последней модификации объекта

Таблица - Атрибуты (Details)
Используется для хранения списка реквизитов
Поля:
ID (INTEGER) - Уникальный номер реквизита
Identifire text NOT null - Наименование реквизита
TypeID INT - ИД типа данных
KindID INT - Ид вида метаданных
Position INT, - Номер позиции у владельца
Synonyme text - Представление
AviliableOn INT - Доступен у... Только для справочников: 0 - везде, 1 - для элемента, 2 - для группы
ValueTypeKind Text - Тип+Вид значения реквизита
IsComposite INT - Признак составного реквизита, используется когда реквизит может принимать значение разных типов, видом метаданных
Len INT - Длина, для чисел и строк
Exactness INT - Точность, для чисел
Positive INT - Признак только положительного значения
Obligatory INT - Признак обязательного реквизита
Indexed INT - Признак индексации значения
IsTable INT - Признак того, что это Табличная часть документа
ParentTable INT - Ид табличной части документа

Таблица - Метаданные (Metadata)
таблица для хранения видов метаданых
Поля:
ID INTEGER PRIMARY KEY - Ид метаданного
TypeID INT - Тип метаданного
ParentID INT - владелец, предок
Identifire Text - Идентификатор
Synonyme Text - Синоним
State INT - Состояние, скорее всего будет в виде
Params Text - Параметры, уникальны для каждого типа данных, разделябтся <|>
Comments Text - Комментарий
DateTimeLastUpdate Text - Дата время последней модификации

вот так примерно.

наследование от базового класса и создание типов метаданных на уровне конфига - гуд, но мне кажется сложно, и так или иначе достаточно базовых классов объектов которые есть в той же 1С для большинства задач.
мое видение системы - задача максимум - среда быстрой разработки бизнес-приложений. задача минимум - фреймворк (набор классов) для разработки на том же C++(QT).
информация о метаданных в подобном виде в любом случае будет удобна и нужна.

Nick писал(а) 16. Января 2008 :: 05:09:

Для всего перечисленного тебе хватит VBScript+WEB+SQL-сервера.
Ты фактически описал вебориентированную среду разработки.
ПС. Такое не планируется. И вообще кончайте холивар разводить. Проблема того не стотит.

На счет метаданных в 1 таблице поддерживаю.


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

Phoenix писал(а) 16. Января 2008 :: 07:13:

Используя не самодельный модуль работы с БД, а интегрируя готовый кирпичик (согласно #0), *что мешает* нам интегрировать его не напрямую и жестко, а через некий интерфейс? Пусть этот плагин так на всегда и останется единственным, но пусть это будет *опция* а не данность?

Интегрируя движок языка и реализуя виртуальную машину, *что не дает нам* сделать это не намертво, а придумать интерфейс, и воткнуть в него этот плагин?

Это дополнительная работа. Да.
Но прикиньте, какого объема ожидается проектик? Не шибко меньше 7.7. При этом, мы сидим не в одном офисе, как авторы 7.7, а раскиданы по городам и странам. Поиск багов и отладка должны быть проще при модульной структуре, особенно если сделать переключение интерфейсов в отладочный режим, так ведь?

Чем вариант 2С плох?
Чем вариант "всё в одном и намертво" хорош?

dnp писал(а) 16. Января 2008 :: 10:03:


Не понял  , пожалуйста по пунктам

Ох, как не нравится мне этот наплыв "идей".
Сила подобных решений в слаженности действий каждого компонента системы и в легкости использования их "сообща". Если вы никогда не проектировали подобных систем пошу не фантазировать, а приземлиться.
Пусть о системе, поддерживающей плагины говорит только тот, кто хоть раз РЕАЛИЗОВЫВАЛ это.

Nick писал(а) 16. Января 2008 :: 10:35:

Из моего опыта работы. Из опыта работы моих друзей, приятелей.
Из форумных "хочу". Да по разному.

Igor-bts писал(а) 16. Января 2008 :: 10:49:

Опыт 1С++ в данном случае неоценимая помощь.

dnp писал(а) 16. Января 2008 :: 10:20:


в 2С я практически избавился от мфк, использую дельфийские библиотеки доступа к данным, пока к мфк привязан UI - работает Prof-uis 2.8 + доработки того чего нет в фриварном продукте. Сейчас перевожу на другую библиотеку не связанную с мфк и кроспратформенную (утверждают). но это не qt ). прорабатываю интерфейсы ( IControlMaanager, IDinControl, iBusinessLogic, IBusinessObject, IScriptCompiler, IDataProvider...), что вообще позволит писать библиотеки на чем угодно.
Основную реализацию Бизнес-Объектов я вижу не на уровне встроенного языка. Это должны быть динамические библиотеки, которые реализуют соответствующие интерфейсы. Хотя идею 2С создавать свои бизнес-объект на уровне платформы тоже считаю конструктивной. Но тут много подводных камней.

==
2 trdm
Ты пишешь, что нужно только добавить парсер своего языка к имеющейся виртмашине. Это не так. Нужно интегрировать эту вм в проект. а для этого, возможно, придется переписать не одну строку кода. возникает проблема интеграции вм и динамических контролов и куча всего. затраты времени будут очень большими.
Вот в qt1l был скриптовый движок а-ля 2С. Почему от него отказались ? А теперь возникает вопрос написания парсера и интеграции его в скурель, который опять-же надо будет подружить с qt, а там опять засада. В этом и проблема использования опесурсных продуктов -  в них очень редко проработан апи. такие продукты пишутся по принципу "давайте взлетим, а заправим потом".

Вот в qt1l был скриптовый движок а-ля 2С. Почему от него отказались ?

trdm писал(а) 16. Января 2008 :: 11:57:

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

Kemet писал(а) 16. Января 2008 :: 12:15:

А зачем тебе ответы на эти вопросы? Я отвечаю - ты стебаешся.
Я стараюсь расскачать проект, как-то организовать, что-то сделать, а ты в эту ветку пишел исключительно рисоваться? Работал у меня 2С. Работал.
Чета с цепи альтернативисты посрывались, на ТиС apogee машет флагом с изображением шарпа так что от пыли просто не продохнуь. Тут ты. Может хватит делить шкуру неубитого медведя?
Иши стронников, собирайтесь и канифольте друг другу мозги вопросами скока влезет. А я чета притомился от ващих страшилок с незавершенными проектами.

Хлопцы и девчата, учтите тот факт, что выложены наброски.

Ну, вот к примеру, добавлю к ТЗ кусочек :
Цитата:

Но тут сразу видишь - начинаются ветвления "Либо", "Если"... То есть структура нужна - какие блоки есть, каких нет (и кто тогда за них)...
То есть имея структуру - наполнить текстом можно. Иначе - смутно всё.

"Готовые блоки", из которых предполагается стройка, таковы :

1. Движок БД низкого уровня (уже выбран SQLite)
2. Движок Интерфейса (уже выбран QT)
3. Движок ПрикладногоЯзыка
4. ... кажется всё. Что-то забыл. Подсказывайте

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

Последнее и будет основной идеей проекта.

"не-1С-ность" в смысле они не сталкивались с 1С.

trdm писал(а) 16. Января 2008 :: 13:54:

Ответы мне нужны чтобы понять цели вашего проекта, поставленные задачи и стратегия и способы их приемлемого решения, которые вы можете предложить или, хотя бы, задачи. Я задаю тебе те вопросы, которые ты сам должен себе задать.
Чтобы "раскачать" проект надо иметь четко осознанные и поставленные цели и провести ревизию доступных средств (не только имеющиеся компоненты, но и их особенности, плюсы, минусы, способы увязки компонентов, ресурсы и т.д.).
Поэтому я задаю наводящие вопросы, и расказываю реальные истории. А то, что для тебя это " страшилки" - хорошо. просто для некоторых это серые будни.
Я не против участия в проекте, сходном с тем над которым работаю. Если бы я имел четкое представление о вашем проекте, я бы знал, чем я могу помочь. Пока же я действительно вижу только размахивание флагом с троллем и пингвином.
А я хочу знать, чего ты хочешь от проекта. Где-то ты сказал, что тебе нужен удобный инструмент для решения своих задач. Что за инструмент? Каким ты его видишь? Какие задачи? Как этот инструмент может тебе облегчить работу? Т.е. я хочу услышать твое видение проблемы. Кроссплатформенный инструмент это не проблема. Проблема в архитектуре твоего представления о прекрасном.
А так я около месяца назад видел проект на wxBasic, который неплохо справлялся с поставленной задачей. В нем был реализован кадровый учет, касса, банк, учет расчетов с подотчетными лицами. И никаких тебе 1с, 2с, 1l и ананасов. Вот такие вот пироги.

trdm писал(а) 16. Января 2008 :: 20:53:

Какого конструирования если с целями неопределились?

я нашел у тебя единственную цель:
Цитата:


но это решается wine + v7.7, более того уже многие это внедряют

Nick писал(а) 16. Января 2008 :: 05:09:

Уже 100 процентов что объекты метаданных будут работать медленнее чем возможно.
Это в любом случае плохо.

Я имею ввиду работу методов встроенных объектов, например Документ.Записать();
ты имел ввиду что метод "Записать" будешь реализовывать на встроенном-интерпретируемом языке?

trdm писал(а) 22. Января 2008 :: 13:49:

Да - Записать на встроенном языке
Записать это по сути Операция с БД как она зависит от встроенного языка?

Phoenix писал(а) 22. Января 2008 :: 14:01:


И что? У меня сейчас есть проект на 1с + MSSQL + 1c++.  Работают  одновременно 10 операторов + обработка из управленческой базы которая этим всем рулит + отчеты
И всё это крутится на одном пне Core Duo c 2Г оперативки

Phoenix писал(а) 22. Января 2008 :: 14:11:

Не понял какой один шаг? У меня все классы написаны на 1с методанных в понятии 1с там нет вообще

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

trdm писал(а) 22. Января 2008 :: 13:49:

К примеру в 1С код на всторенном языке исполняется не непосредственно, а будучи скомпилен в <как оно там называется>. Что несколько (на сколько?) ускоряет его исполнение

А что должен делать метод "Записать"? Что-то типа SQL-запроса?

А сложно сделать так, чтобы исходно "Записать" (ну, в смысле - все методы базовых объектов) был на всторенном языке, но был переключатель, через который можно было бы подключить DLL? В таком варианте прототип заработал бы гораздо быстрее, а некоторым и большого быстродействия не надо, так они бы и не перешли бы на ДЛЛ-ку
Отработали прототип - перенесли на С++ и зашлифовали.

Плюс: потом к быстрой проге на С++ захотелось прикрутить хитровыделанный объект? Но не уверен, что он приживется? Сбацал медленный прототип на ВЯ, посмотрел - стОит\не стОит.
С++ снова только для устаканившегося решения.

ЗЫЖ Не пойми меня неправильно, я в эту сторону не давлю, а только интересуюсь, раз уж ты, сначала осадив наш пыл, всё же тему "идей 2С" не поставил на игнор

По честному - я не представляю, на сколько такая "двух-прикруточность" трудно реализуема.

Ну основное время как правило это выборки данных.
А вариант такой:
ядро системы - это главное окно программы, язык, механизмы работы с метаданными, интерфейс по регистрации модулей.
Плагины, или модули, при подключении  сообщают ядру какие классы, методы свойства этих классов содержат в себе.
возможно регистрируют  свой тип метаданных.
1с функционирует похожим образом?

З.Ы. trdm, надеюсь сразу на землю не будешь опускать?
Это пока измышления.

Nick писал(а) 22. Января 2008 :: 20:24:

http://ru.wikipedia.org/wiki/Java
http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82%D0...
http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%B5%D1...

Цитата:


Если ты забыл то модуль проведения мы пишем на языке 1с , и основное время там как правило тратится на выборку данных, а не на их запись. То есть в моей интерпритации добавляется механизм регистров и операций на интерпритируемом языке. Но его я бы постарался реализовывать не так как 1с. Что из себя представляет в общем случае модуль проведения 1с?  - Перебор строк документа и запись потом их данных в регистры. Спрашивается зачем тянуть данные на клент если их потом писать на сервер? Т.е в простейшем случае модуль проведения я бы реализовывал как insert (a, b ,c) ( Select .... From ДокументСтроки). Надеюсь понятно объяснил ?

lustin писал(а) 23. Января 2008 :: 05:43:


При разработке метаданных в конфигураторе это вполне реализуемо

trdm писал(а) 22. Января 2008 :: 13:49:

Что, по твоему мнению, должен делать метод документа/справочника "Записать"? Почему это будет тормозить?
По моему вот, например, так:

Функция Записать()
   Попытка
     ИБ.НачатьТранзакцию();
     Шапка.Записать();
     Для каждого ТЧ из ТабличныеЧасти
     Цикл
        ТЧ.Записать();
     КонецЦикла;
     ИБ.ЗафиксироватьТранзакцию();
     Результат = Истина;
   Исключение
     Результат = Ложь;
     ИБ.ОтменитьТранзакцию();
     ...
   КонецПопытки;
   Возврат Результат;
КонецФункции;
=
Т.к. "Шапка", "ТабличнаяЧасть" - это, по сути, источники данных (DataSet'ы),то особых тормозов при записи наблюдаться не будет, т.к. "Записать" это вызов метода
"DataSet".ApplyUpdates();

Цитата:


Ну если все правильно сделано то это просто переход по индексу

dnp писал(а) 24. Января 2008 :: 05:12:

Вот кстати да все про интерпритаторы да про интерпитаторы, есть же кэш!

Nick писал(а) 24. Января 2008 :: 05:15:

Какой кэш? чего?
Поясню - под интерпретацией понимается эмуляция некой виртуальной машины.
Эмуляция бывает аппаратная и программная.
Нам доступна программная.
Если просто,
Байт-код представляет собой систему команд этой виртуальной машины (ВМ). ВМ производит выборку команд, анализирует их и транслирует в соответствующие вызовы.

потому что аппаратная реализация фаз декодирования, анализа и выполнения команды всяко быстрее программной.

Уважаемый trdm, а вот в теме "Набросок ТЗ по qt1L. Первые шаги"
чего для тебя больше, "Набросок ТЗ... Первые шаги"
или все-таки "по qt1L." ?

Просто если второе, то есть типа - опираясь на то, что уже есть, то хорошо бы знать, а что уже есть? Исходники смотреть или кто-то может рассказать?

А если первое - то ... Дайте ещё аргументов против "трёхзвенки 2С" 

Nick писал(а) 24. Января 2008 :: 09:07:

Ну вот, допрыгался...
Здесь есть люди, которые более меня в курсе. Но всё же скажу.
Уровней три:
0. Простое и быстрое ядро на С++ и embedd'ах
1. Набор базовых объектов Метаданных
2. Метаданные унаследованные от Базовых из "1"

0. содержит ВМ исполняющий байт-код и компилер прикладного языка в байт-код, ДвижокИнтерфейса, ДвижокБД (или интерфейс), прочие НеХранимые спец-объекты (Таблица, Текст, ТаблицаЗначений, СписокЗначений, .... )
1. это то, что в 7.7 мы видим, открыв пустую конфигурацию, только не вшитое жестко в  среду, а созданное визуально + наполненное кодом на прикладном языке. Именно на этом уровне прописано, как работать с движком БД при выполнении действий типа Записать, СделатьНепроведенным, Провести, Удалить. Можно делать версии, оптимизированные для разныж ДвижковБД нижнего уровня.
2. обычная конфигурация, имеющая в общем уже знакомую нам идею.

ЗЫЖ
Не всё, что я написал, уже есть в 2С, но идея была примерно такова

А почему бы в ядре системы не предусмотреть интерфейс через который регистрируются бизнес объекты написанные как на встроенном языке так и в виде объектов встроенных в платформу?
и каждый пишет на том что ему удобно.
По описанию VM squirel, предлагаемого trdm это возможно?

trdm писал(а) 24. Января 2008 :: 11:34:

Что то судя по вопросам ты от неё не в восторге

Nick писал(а) 24. Января 2008 :: 11:53:

Точно, не в восторге. Я представляю скока прийдется програмить на таком решении, что-бы получить мало мальски рабочую конфигурацию. Поэтому она мне не нравится.
планируя проект, я стараюсь решить проблему: больше результатов за меньшее время.
А вы тут просто развлекаловку устроили>>состязания фантастов...

мы же не фантастику пишем..

trdm писал(а) 24. Января 2008 :: 12:48:


А сколько времени понадобится что бы сделать "монолит"?
так хоть можно разделить на части. Да и ядро системы будет простым.

А сайт проекта http://1l.w4b.ru/ уже не живет совсем что ли?
Антивирус на трояна ругается, да и последние новости за 2005 год.
Было бы удобно продолжать использовать сайт для выкладывания
последних новостей по проекту. Или какой другой сделать.

Не нашел там описания ТЗ.
То ли плохо искал, то ли нет его там.
Попросил Trdm на мыло выслать, как придет, гляну.

trdm писал(а) 04. Февраля 2008 :: 09:51:

Зачем программы корежить? Их писать надо))
Я пока над GUI'ем работаю. Интересная это вещь, оказывается.
А вообще я тут давеча Thunderbird себе поставил. В довесок к давно используемому фоксу. И тут у меня мысля появилась наверное там гуй-то имеется в виде библы, его что-ли использовать? не интересовался этим просто никогда. мож кто знает что за перец этот мозилла-гуй и с чем его едят?