![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Ад со вшами жолтыми
С некоторых пор ничто так не бесит, как восход солнца вручную реализация систем типов и разного рода классов-объектов поверх уже существующих языков.
Вот к примеру, задача: есть система, в ней настройки. Настроек очень дохренища, настройки могут быть привязаны к 4 уровням иерархии(общие, подразделение, профиль пользователя, пользователь), и на каждом уровне переопределять предыдущий.
Формально настройки являются просто очень большим объектом с кучей полей разнообразных типов. Но из-за переопределения, к каждой сущности такой объект не привяжешь, или к каждому полю придется цеплять флаг "есть значение". Поэтому поля хранятся в словаре <имя_поля,значение_поля>. Уже цирк с конями.
Затем начинаются пляски с бубном "как бы это все аккуратно показать в GUI". Нарисовать руками редактор с закладками для 100 полей - увольте, я сдохну это поддерживать, если что-то добавится. Поэтому все поля показываются в гридах(ну типа как в мозиле, about:config, только по категориям разбит, чтобы юзеру проще мышой шароебиццо было). А часть настроек, сука, всякие массивы или списки типа "список подписей и расположения полей в отчетных гридах" или "список кастомных полей документа с подписями и типами". И все это при аккуратной реализации (чтобы было удобно юзеру и не требовало стояния на ушах при поддержке) настолько удалбывает - не передать.
Это еще хорошо, что 2/3 кода для этой пакости генерируется прямо из специальной базы данных, где вся эта модель конфигурации описана и редактируется культурно прямо в гриде, а не блин редактированием тысячестрочных исходников и SQL запросов.
Вот к примеру, задача: есть система, в ней настройки. Настроек очень дохренища, настройки могут быть привязаны к 4 уровням иерархии(общие, подразделение, профиль пользователя, пользователь), и на каждом уровне переопределять предыдущий.
Формально настройки являются просто очень большим объектом с кучей полей разнообразных типов. Но из-за переопределения, к каждой сущности такой объект не привяжешь, или к каждому полю придется цеплять флаг "есть значение". Поэтому поля хранятся в словаре <имя_поля,значение_поля>. Уже цирк с конями.
Затем начинаются пляски с бубном "как бы это все аккуратно показать в GUI". Нарисовать руками редактор с закладками для 100 полей - увольте, я сдохну это поддерживать, если что-то добавится. Поэтому все поля показываются в гридах(ну типа как в мозиле, about:config, только по категориям разбит, чтобы юзеру проще мышой шароебиццо было). А часть настроек, сука, всякие массивы или списки типа "список подписей и расположения полей в отчетных гридах" или "список кастомных полей документа с подписями и типами". И все это при аккуратной реализации (чтобы было удобно юзеру и не требовало стояния на ушах при поддержке) настолько удалбывает - не передать.
Это еще хорошо, что 2/3 кода для этой пакости генерируется прямо из специальной базы данных, где вся эта модель конфигурации описана и редактируется культурно прямо в гриде, а не блин редактированием тысячестрочных исходников и SQL запросов.
no subject
Нечитабельно в принципе. Редактированию поддается с трудом. Нет возможности проверки валидности на уровне БД(списки ключей - только в коде).
Я сейчас делаю наоборот: данные изначально в специальной базе данных, из нее генерируются скрипты заполнения основной базы, исходный код объекта с атрибутами, код загрузки-сохранения, и прочее. А от генератора гуи для редактора я отказался - там вылазят такие кошмары, если хочется сделать что-то сложнее редактора простых типов, что проще все таки пока с гридом работать. Да, и дерево там тоже есть.