Цитата:

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

Иначе будут реальные тормоза при попытке создания неизвестных объектов - все-таки работа с файлами

artbear
Цитата:


Скажи, для чего разработчику  прикладных решений нужно заморачиваться этими схемами?

Предлагаю взглянуть на этот вопрос по-новому, отбросив стереотипы ["в каждой базе должен быть список подключаемых классов"]: разработчик создает классы, помещает их в специальное хранилище и всё! Остальные вопросы решает платформа! Детали я уже приводил выше.

зы: думаю, все преимущества такой схемы очевидны. Или нужно расписать?

ззы: тормозов будет не больше, а, скорее, даже меньше - обрабатываться будут только действительно используемые классы.

Arta
В огороде бузина, во Киеве дядька. 

Arta
Ну, во-первых, хранилище классов - это сейчас не самое главное. Пока, я предлагаю одну простую вещь: оставить все как есть и, внимание, избавить программиста от необходимости регистрировать КОП в дефцлс. Только и всего! Решение этой задачи позволит, в дальнейшем, организовать более удобный способ хранения классов, как это сделано в жаве и дотнете.

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

Цитата:


Расписывать преимущества не надо. Надо расписать недостатки.

Идея со специальной папкой мне не нравится. Так как у каждого отчета может быть своя специальная папка.

Палыч
Один в один в отношении моих замечаний в целом, и совместимости в частности.

Так... После проведения многочисленных межправительственных консультаций...

При создании класса, наиболее оптимальным видится следующий вариант (в порядке следования):
1. Если класс прописан в defcls.prm, то создаем прописанный там класс (для обратной совместимости)
2. Смотрим предопределенный каталог внутри базы, где имя класса = имя файла (например узкоспециальные классы для конкретной базы)
3. Смотрим (по аналогии с java) %classpath%. classpath можем прописать в ини, может установить методом, как угодно в общем. Имя класса также равно имени файла. В classpath конечно может быть несколько путей.

Таким образом мы сможем:

• отказаться от defcls.prm
• придержимся обратной совместимости
• сможем хранить что угодно в хранилищах помимо классов
• и... при таком варианте станет ненужным новый метод Артура

Устраивает, но и свой метод не удалю
Мне лично нравится автоподключение нужных классов для любого нужного набора - отчетов и классов !