Ад со вшами жолтыми
С некоторых пор ничто так не бесит, как восход солнца вручную реализация систем типов и разного рода классов-объектов поверх уже существующих языков.
Вот к примеру, задача: есть система, в ней настройки. Настроек очень дохренища, настройки могут быть привязаны к 4 уровням иерархии(общие, подразделение, профиль пользователя, пользователь), и на каждом уровне переопределять предыдущий.
Формально настройки являются просто очень большим объектом с кучей полей разнообразных типов. Но из-за переопределения, к каждой сущности такой объект не привяжешь, или к каждому полю придется цеплять флаг "есть значение". Поэтому поля хранятся в словаре <имя_поля,значение_поля>. Уже цирк с конями.
Затем начинаются пляски с бубном "как бы это все аккуратно показать в GUI". Нарисовать руками редактор с закладками для 100 полей - увольте, я сдохну это поддерживать, если что-то добавится. Поэтому все поля показываются в гридах(ну типа как в мозиле, about:config, только по категориям разбит, чтобы юзеру проще мышой шароебиццо было). А часть настроек, сука, всякие массивы или списки типа "список подписей и расположения полей в отчетных гридах" или "список кастомных полей документа с подписями и типами". И все это при аккуратной реализации (чтобы было удобно юзеру и не требовало стояния на ушах при поддержке) настолько удалбывает - не передать.
Это еще хорошо, что 2/3 кода для этой пакости генерируется прямо из специальной базы данных, где вся эта модель конфигурации описана и редактируется культурно прямо в гриде, а не блин редактированием тысячестрочных исходников и SQL запросов.
Вот к примеру, задача: есть система, в ней настройки. Настроек очень дохренища, настройки могут быть привязаны к 4 уровням иерархии(общие, подразделение, профиль пользователя, пользователь), и на каждом уровне переопределять предыдущий.
Формально настройки являются просто очень большим объектом с кучей полей разнообразных типов. Но из-за переопределения, к каждой сущности такой объект не привяжешь, или к каждому полю придется цеплять флаг "есть значение". Поэтому поля хранятся в словаре <имя_поля,значение_поля>. Уже цирк с конями.
Затем начинаются пляски с бубном "как бы это все аккуратно показать в GUI". Нарисовать руками редактор с закладками для 100 полей - увольте, я сдохну это поддерживать, если что-то добавится. Поэтому все поля показываются в гридах(ну типа как в мозиле, about:config, только по категориям разбит, чтобы юзеру проще мышой шароебиццо было). А часть настроек, сука, всякие массивы или списки типа "список подписей и расположения полей в отчетных гридах" или "список кастомных полей документа с подписями и типами". И все это при аккуратной реализации (чтобы было удобно юзеру и не требовало стояния на ушах при поддержке) настолько удалбывает - не передать.
Это еще хорошо, что 2/3 кода для этой пакости генерируется прямо из специальной базы данных, где вся эта модель конфигурации описана и редактируется культурно прямо в гриде, а не блин редактированием тысячестрочных исходников и SQL запросов.
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
no subject
там имено такое. объектная БД поверх реляционной. только аттрибуты переопределяются в иерархии объект - абстрактный документ - внутренний документ - внутреннее поручение...
+ для всех полей права доступа по юзверям и группам %(
(no subject)
а если серпом по яйцам
/надел каску и залез в окоп/
Re: а если серпом по яйцам
(no subject)
(no subject)
(no subject)