Тут недавно была тема Ищу работу методиста-разработчика (+конфа "с нуля" за 2 недели внутри) я вот решил тоже себя замотивировать.

Решил написать прототип модульной конфигурации (в голове есть реальная картинка), то есть которая будет реально состоять из модулей, каждый модуль будет полностью независимым CF, модули можно будет как добавлять так и удалять без каких - либо тяжелых последствий.

Сроков не назначаю, торопится не буду, выложить проект не обещаю.

Кратко опишу чего я хочу сделать:

Модуль это корневая подсистема, CF содержит только одну подсистему и объекты входящие в нее, ни один объект не может входить в несколько подсистем.

Будет одна предопределенная подсистема "Ядро" которая будет все связываться, связи будут строится на пользовательских данных

Интерфейс планирую сделать альтернативно от 1с.

В данной теме буду подкидывать те или иные заморочки которые вылезли при реализации, для обсуждения

Люблю модульные приложения.

У доминиканы какакя-то фигня сейчас получается

кстати, связи на пользовательских данных - шлак. Мильон галочек каждый раз тыкать приходится

когда новую фичу запиливаешь

а потом этот мильон переносишь из базы разработчика в общетестовую, а потом из общетестовой в продакшн...

Даже вот так, но только ближе к концу августа

т.е. модули никак не могут пересекаться? и о чем будет конфа?

1С и модульность? Давно решено как модуль обработок в аппмусе, рарусе, бите и куче других конф. Добавлять модули без изменения структуры данных слишком медленно для работы - не взлетит.
Нормальная архитектура и програмирование по стандарту позволяет не думать о модульности совсем.
P.S. Типовые зоопарки такие как УТ+CRM+Логистика+Договора видел далеко от нормы.

(7) должны быть хорошо изолированные модули + прописана иерархия зависимостей, желательно без колец

(9)+ а как опциональные зависимости делать - вообще ХЗ

(10)+ типа как Торговля - WMS. WMS может быть отдельно, но если есть Торговля, то документы склада на основании реализаций вводить, например...

Как собирать модули в 1 конфигурацию?
Например, на 8.3 через объединение xml-ек

http://pypy.org/
https://help.ubuntu.com/community/AptGet/Howto
https://npmjs.org/
http://bundler.io/
https://npmjs.org/package/browserify

(0)Тоже бы себя чем нибудь замотивировать!

Интересно что такой альтернативный интерфейс? Как в Windows 8 бы сделал,было бы круто.

Давайте замутим - Проект ГОА , главное не заторчаться

полюбому все упрется в то что ядро должно содержать почти все подсистемы.
а вот как будут создаваться роли? У каждого юзера будет роль для каждой подсистемы? в этом списке можно ведь и потеряться будет!

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

(18) это просто - они оба зависят от "Базы", где есть "номенклатура". А вот опциональность - беда

но вообще - скорее всего в 9ке будет модульность

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

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

(0) один устанешь писать.
если надо - могу помочь.
альтруизмом не страдаю, буду работать на перспективу.

надо как-то разнообразить болото рутины

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

(21) специфические реквизиты - можно через подчиненный справочник или РС

т. е. вместо гибкого инструмента, я максимум что могу сделать - добавить реквизит в справочник? ну и что делать с отчетом остатки товара, будем дублировать, или ждать когда в ядро добавят?

(26) это и сейчас есть в ут11 и бп3 через тч

(0) Еще одна БСП? Зачем?

(29) Нет. Посмотри на openerp.com что такое модульность...

для начала придется написать свой конфигуратор

или конфигурцию которая сможет это все собрать в одно правильно

(28) ненене, РС с одним ведущим измерением - ссылкой на справочник из расширяемого модуля и ресурсами - нашими реквизитами, а не как сделаны допреквизиты. тогда этот РС возможно включить в состав расширяющего модуля. Отчеты по входящим в состав модуля регистрам - в составе модуля или внешние. соответственно - у торговли Товары на складах, у WMS - товары на складах по ячейкам, или как-то так. Небольшое дублирование в любом случае будет, да.

(31) А потом к нему, кто-то напишет - модопат

(30) В английском не силен, внятных реализаций не видел, кроме как в закрытых системах.

(0) УАТ когда нибудь и т.д. встраивать приходилось? А идея - хорошая, не новая, правда.

"Каждый дрочит как он хочит"

кто то велокаты изобретает.
кто то модульных монструозных конфигураций пишет...

(38) Это - аргумент. Но я подглядывать не люблю, тем более за...

да!

(0) Как ты решишь проблему с одинаковыми процедурами? Мысль хотя бы, или дублировать во всех подсистемах?

(30) А можно в двух словах, желательно с учетом возможностей 1С и заявленных в (0) требований

(0) Залезь в УПП и включи галку для проверки наличия модулей. Вот уже есть модульная конфигурация.

В смысле расширенную проверку.

(33) а какая разница? Ничем от ТЧ не отличается

(36) мне приходилось и с БП и с УПП

(44) ТЧ - часть объекта. общий РС допсвойств - часть базового модуля. Описанный мной РС - часть того модуля, которому нужны эти реквизиты.

(46)+ изоляция друг от друга

(46) Работало сразу? И после обновления все нормально? Я и в УТ запихивал, меряться будем?

(46) Мы же вроде бы определились, что объект у нас находится в ядре

(49) ты спросил, как быть со специфическими для модуля реквизитами объекта

поэтому что общий РС, что ТЧ справочника - это всё объекты ядра, т.е. базового модуля

(50) Да, не вижу припятствие сделать как в УТ11, т.е. кидать их в ТЧ все эти "специфическими для модуля реквизитами"

(47) Какая изоляция? Технология где? Можно конечно определять что за состав компонент, но отладить - нереально.
Где ответ Не взлетит?

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

(53) А зачем тебе изоляция? типовые отчеты не знают о пользовательских реквизитах, но тем не менее можно в отчетах их выбирать и использовать

даешь!

(54) Т.е. пихать регистр гуд, а ПВХ - это плохо? А можно список что тако5е хорошо, и что такое плохо?

(57) ПВХ для реляционных баз объект сильно искусственный, и при возможности стараюсь его избегать, либо очень внимательно проектировать.

Зачем на платформе для ларьков пытаться реализовать функционал серьезной системы?

Один я не верю в модульные, а тем более универсальные, конфигурации на 1С? Лучше бы больше решений, красивых, легких да разных, чтобы было из чего выбрать. Ховнонастройки над типовыми 1С - не в счет.

Ах, да.

Заказал программисту подсистему "Метаконфигуратор", для динамического размещения допреквизитов(находящихся либо в общих реквизитах, либо в справочниках, либо в РС, либо нетиповые реквизиты самого объекта) любого объекта на форме (ака допреквизитов у справочников в УТ11). На инфостарте вроде была тема по типу мистовской книги знаний. Сегодня посмотрю начальный вариант что он там натворил :)
Нужно это чтобы на обновления по минимуму время тратить.

(59) Ну это смотря как кто что использует. Не любите кошек?

Хотя, какая идея, без предложения технологии, или идеи, такое и обсуждение.

(63) куда ни ткни упрешься в нелогичные ограничения платформы,   либо придется столько наворачивать кода, что запотеешь кодить.

(65) Давайте перейдем в NoSql, там все проще. Назовите конкретно.

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

(67) это по типу отговорите меня, а то и вправду начну ;)

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

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

(0) Это тебе навеял мой вопрос на ИС в интервью Нуралиеву??

Ничерта без фирмы 1С и вмешательства в платформу не взлетит!!!!! Даже не парься.

(71) за 5 дней до твоего вопроса я статейку опубликовал :) наверно ты ее не читал :)

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

Или модуль доставки - бах а он там ...

Из нее хренас два ты сделаешь выделенный CF содержащий только ее объекты.

Это интересно. Здесь мне кажется самым сложным спроектировать удачно.

прототип ядра уже итак есть, это БСП.
можно к нему лепить любые cf с подсистемами. но ведь не в этом суть.

(75) Уже не теоретики пошли. Я про это и говорил.

...ни один объект не может входить в несколько подсистем.

Как это? Что тут объект? Справочник номенклатура? Он же во многих процессах задействован.

(0) Нет автор не потянет. Если сама 1С пойдет...

Цитата: Интерфейс планирую сделать альтернативно от 1с.

Приведи пример хоть какой-то другой реализации от кого-то...

Прототип модулей есть? Какая нить система. Я бы наверное делал  модули как набор процессов. У модуля есть входы и выходы. Через них они взаимодействуют между собой.

+(80) Ядро содержит объекты метаданных, через которые организуется обмен данными между модулями, и набор правил взаимодействия модулей, то есть возможные комбинации входов, выходов. Как то так рисуется картина.

(77) тогда уже лучше наследование объектов

Лето, жара. Вот и Доминикана, ждемс. Только не первый, увы, но попытка (обозначение)...

А вообще, Бухня, ЗУП и УТ, вот тебе и модули.

(75)(76) Вы когда ни будь программировали например компоненты к дельфи? а я реально делал... посмотрим

(85) Я еще на Паскале, Фортране, перфокарты застал. Смотрельщик. Тут даже смотреть нечего.

(86) я не про перфокарты а про компоненты, это слегка разное...

(0) все таки я наверное классический тупой 1сник - не могу представить как один объект не будет входить в несколько подсистем. Те же товары используються везде почти. Или не допонял автора?
а вообще идея очень хорошая. Тем более на упрформах с опциями реализовать проще

(88) Он хочет УПП в виде базового ядра а ему остается только отчеты рисовать в виде модулей

(88) Опции тут как раз не при делах. Опции просто управляют видимостью реквизитов.
Сама идея уже давно сидит в голове. Сделать одну супер систему что бы можно было галочками сделать нужную тебе конфигурацию. Модули потом можно писать, продавать, распостранять и тд. В общем можно было бы зажигательную штуку замутить. При условии, что бы она была открытой. Тогда это будет "ваще агонь!"

(0) Мысль интересная, того же плана, что и регистр сведений реализовать на 7.7.
Но на 8 уже и БСП есть, и желание 1С делать идентичные комплексы модулей в конфах на УП.
Наверно, желание навеяно этой темой http://job.mista.ru/topic.php?id=670771&page=1
Как говорил товарищ Берия, попытка - не пытка.

я храню модули в формах обработки
в CF конечно можно более гибко хранить. но подключать не понятно как.

краткий отчет
что сделано
1. Сделан тестовый механизм хранения и подключения модулей, для каждого модуля ведется своя версия, список других модулей (с их версиями) которые обязательно нужны текущему модулю. Начал делать систему инкапсуляции в код модулей новых модулей
2. Для теста начал делать блоки "УправлениеПользователями", "СкладскойУчетБазовый", "СкладскойУчетПартионный", "СкладскойУчетПоСредней"

пока неразрешимых задач не вижу.

(93)Тут глазам их открылось не то тридцать, не то сорок ветряных мельниц, стоявших среди поля, и как скоро увидел их Дон Кихот, то обратился к своему оруженосцу с такими словами:

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

Ну посмотри же на что-то кроме 1С. Типа www.openrp.com

сам давно пытался, да времени нет
жена, дети, братья наши меньшие
но если чотий мэн взялся, имей меня в виду
я шестую нормальную форму знаю, и в Уф собаку съел
рассчитывай на меня, короче

только не верю,что получится

В целом мои эксперимены закончились, моя задача была достигнута. Задачей я для себя ставил создание "прототипа", то есть упрощенной модели на основании которой будут видны все проблеммные места и на основании которой можно написать реальное ТЗ.

Что реально сделать:
1. Система разделенная на блоки, каждый блок устанавливается и удаляется в 3 этапа, загрузка методанных, включение связей, выполнение обработок по заполнению данных. Примеры блоков "Склад, СкладПартионный, СкладПоСредней"
2. Временное отключение всего блока из пользовательского режима
3. Для каждого блока ведется версия, и связи с другими блоками
4. Объект блока можно расширять другим блоком, например в блоке Склад есть документ ОприходываниеТМЦ с ТЧ Товар в которой 2 колонки "Номенклатура" и "Количество", Блок "СкладПартионный" добавит в нее колонку "Партия", а Блок "СкладПоСредней" добавит "Сумма". При этом будут использоваться новые регистры, при этом модуль "Склад" будет корректно обращатся к новым регистрам.
5. Расширение форм, к сожалению полное переопределение формы сделать нельзя, но можно реализовать динамическое формирование путем обьединения нескольких форм из разных подсистем. Правда при этом будут некоторые ограничения связанные с конткстом осеновной формы, но не смотря на ограничения большенство задачь вполне решаемые.
6. Не удается корректно расширять "КритерииОтбора", "Права", "Последовательности"

Не тестировал на скорость, по понятным причинам :) до конца не реализовал типизацию расширяемых реквизитов и работу с запросами.

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

Если будет обновление - буду следить

100

Пока 1с не сможет работать с несколькими конфигурациями/базами (а
это возможно никогда не случится) - вся эта затея шлак

(98) Как и предполагалось в (67) - поигрался и бросил. Спрашивается - зачем надо было вообще тему заводить?

(101) +100 - Не на 1С. Теоретически можно выхолостить задачу до собирания кубиков - реальные задачи далеки от этого. Жизнь то своя. Не жалко? Почему бы тогда не нарисовать что-нибудь альтернативное 1С ? :)

(98) а я то думал, эх...

(102) я не альтруист, оформлю реальную концепцию и пойду искать заказчиков.

хм
[удалено самоцензурой]

(105) на кикстартере проект заведи )))

(105) Альтруимз тут не причем... Кого ты видишь в качестве заказчика ? кому это будет реально интересно? (имеется ввиду кто захочет спонсировать данный проект). Разве что доминиканцы....но они больше по части пиара специалисты. Вот если бы ты сделал то, что декларировал (что бы готовность была процентов 90) вот тогда можно идти и заинтересовывать кого нить а так бессмысленно (имхо)

(108) то что я задекларировал это как минимум месяц плотной работы для пары человек.

Зачем делать то за что могут не заплатить.

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

(0) Чет я нифига не понял. Если в рамках одной БД 1С - то непонятно, нафига сыр-бор с разными CF. Если в разных - то бедность способов их взаимодействия вызывает тот же вопрос.

(110)

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

Что получит Клиент:
- Платить кусками, получить только то что ему нужно, использовать триальные модули (с последующей безопасной деинсталяцией)

(111) твоя модульность может будет прикрепляться к типовым?

(112) нет не будет (разные идеологии), по этому сабж сильно затратен, и не выполним в одиночку.

Собственно это некий шаг не вперед а вбок, в другое измерение. При этом много чего пострадает. Но мне кажется что плюсы из (111) на столько перевешивают все минусу, что можно рискнуть.

(113) тогда кому будет нужна твоя разработка? Ты много видел тиражных решений не основанных на типовых?

(111) Вопрос отдельной продажи модулей твоя штука никак не решает. Т.к. это касается вопроса защиты. А если реализовывать защиту - то никакой проблемы сделать лицензии на модуля и в рамках одной конфы нет.

(109)
>>Зачем делать то за что могут не заплатить.
Зачем тогда вообще было, что-то начинать делать (а точнее не делать а фантазировать)

>>я как художник сделал эскиз, если кто готов купить картину - я напишу.

Художник пишет картину вне зависимости купят ее или нет - если чисто  на продажу то уже не художник а коммерсант (это надо четко разделять)

(113)
>>Но мне кажется что плюсы из (111) на столько перевешивают все минусу, что можно рискнуть.

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

vde69 Сама по себе идея очень хорошая, но идея как таковая живет уже лет 10 наверно (еще с появления 8.0)

(111) Да и вообще красивое слово "модульность" - нифига не панацея на самом деле.
Чем выше изоляция модулей - тем хуже их интегрируемость.
Золотую середину тут очень нелегко найти.
Можно супер-пупер модульную систему нарисовать с микроядром, которую никто покупать не будет. Потому что в итоге комплексные решения окажутся более "юзабельные".
А если повышать интегрируемость - то тут же хана всем плюсам автономности модулей и простоте интерфейса их взаимодействия.

Не взлетит

Судя по темам на разных форумах, автор в этом году в казино проигрался.

(120) ты-бы смайлик ставил.... или ссылку давал

я в казино ни разу в жизни не играл :) и вообще последних 20 лет на деньги не играл.

(121) у тебя у концепция уже готова?

(122)http://forum.infostart.ru/forum1/topic89281/

(121)
Я вот в (0) прочитал:
"Интерфейс планирую сделать альтернативно от 1с."
- и тоже смайлик не вижу.

(0)  -интересны два момента:
1) автор пиарил создание необычайного компонентного "велоката" на платформе 1С, где даже ООП нету. Раньше знал    vde69 как весьма здравомыслящего, удивлён.
2) авто слился -ну, это понятно.
Таких "дерзких мечтателей" полно на инфостарте, одни стартапы стартапят, вторые пишут компилятор из 1с в C#(уже не пишут), третьи отлаживают на низком уровне веб клиент в 1с, четвёртые постят с планшета в "волшебный форум", сидя на толчке в туалете.

реально не хватает бложика, грустно как-то

(123) это НЕ концепция, это голимая реклама

(125) ООП в 1С - эх, НЕ ДОЖИТЬ МНЕ ДО ЭТОГО

Утопия. В реальных задачах не взлетит.

тухлый выкидыш получится. Особенно, если два подключаемых блока будут требоваться для какого-нибудь третьего. В этом случае всех троих в ядро въедрять придется.
Да и втаскивать метаданные (соединительные п**дюлины, которыми модули соединяются) в данные - это совершенно убогая затея. По опыту такие штуки всегда работают медленно, имеют херову тонну галок и мне уже отсюда видно, что это все будет тормозить и глючить

ещё как интересно ))

собственно

Полностью изолированные подсистемы, а-ля cf, не взлетит, т.к., по сути, они должны быть в конечном итоге связаны.
Т.е. , например, в cf-2 реквизит объекта должен быть типа объекта cf-1, а такого в cf-2 нет. Можно, проставить ему Любая ссылка, или просто объект (СправочникСсылка и т.п.), но это ничего не решит, т.к. все равно, соединять нужно будет конкретно по конфигурациям

(133) а кто тебе сказал, что теквизиты должны визически хранится в документе? как реализован например механизм характеристик?

(130) ничего страшного не случится, каждый модуль будет реализовывать свою логику, тупо кто мешает сделать 2 регистра, да так сейчас и сделано, напримрер регистры "ТоварыНаСкладах" и "ПартииТоваровНаСкладах"

(127) писать полное ТЗ для ушлого руководителя, тогда я нафига нужен? У меня есть концепция и я ее могу обсудить с заинтересовыными людьми...

есть хороший принцеп:
Если я это смогу продать одному, значит я это смогу продать всем :)

(134) на (133) - а как в ПВХ назначить тип, которого в конфигурации нет ?

(133) у тебя вся конфа на характеристиках?
Друпал решил сделать?

(134) не тз концепция, идея.
Боишься что украдут? вряд ли

(136) - этот вопрос не ко мне, а к vde69

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

(135) (136) нет, я только пример привел, у меня другая метода.

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

(140) интересно...

бугага ...

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

галки с планах обмена, подписках, ролях, планах видов всего подряд ставить будет весьма весело.
Ну, в общем, получится БСП, только еще более унылая

1. Интересно как строить вменяемые интерфейсы при разных модулях?
2. Можно ли скрещивать совершенно нестыкуемые вещи, например берем ЗУП+УТ, а БП не берем?
3. Будет ли задействовано ООП?
4. Наконец, в какой среде разработка ведется?

(145) тут в принципе платформу надо менять: поставка в виде нескольких ИБ, соответственно, в дереве конфигурации несколько конфигураций и ссылки между ними - вот тогда заработает по милую душу

(145)
1. только программно, от типового интерфейса толку нет
2. по идеи да
3. реализовано Инкаспулирование и местами Наследование
4. 1с

(147) кстати упр формы или обычные?

(148) УФ,
(147)+ основной упор именно на Инкаспулирование сделан, по тому как именно расширяемые модули дают функционал базовому который и собирает все.