Подарки от программис'тов
Во, ещё нашёл - он обрабатывает это перечисление двумя if:
if(Invisible)
else if(Collapsed)
и в зависимости от этого добавляет стили. Но ниже ещё проверки идут
if(Enabled)
else if(Disabled)
и опять стили применяет. При этом эти две ветки проверок идут независимо поочереди. Но ведь перечисление-то взаимоисключаемое!
Ну это по-моему совсем уже детская ошибка. Тут явно надо разделить на два перечисления (или булевых свойства) или добавить битовые флаги.
Похоже, он использует перечисление просто как хранилище кучи малосвязанных друг с другом значений.
Не говоря уже о том, что такая обработка в разы раздувает код. Было бы два булевых свойства, то все проверки были бы однострочные (через тот же ?: оператор или просто через ==), а так он городит if-else на полэкрана кода.
А без паблик сеттера, но с паблик методом установки - необычное.
------
Поработал бы с Жабой - было бы обычным...
В Жабе вроде вообще испокон веков сеттеры и геттеры методами реализовывались, нет? Не знаю, есть ли у них сейчас аналоги шарповских свойств. Но в том-то и дело, что если бы были чисто методы или чисто свойства - вопросов нет. А когда мешают в кучу разные подходы - где консистентность? Начинаешь думать, что за этим стоит какое-то тайное знание, высшая логика, недоступная простым смертным. А чаще оказывается, что чел намудрил что-то, неподумав, да так и оставил.
Три варианта:
- передаем на клиента и рисуем
- передаем на клиента и не рисуем
- не передаем на клиента
Что непонятного то?
Непонятно то, что разбирая логику этого, видишь, что оно не используется так, а используется по сути два несвязанных набора данных в одном наборе (энуме) - как я выше сказал. Т.е. в реальности оно используется как два независимых варианта по два зависимых варианта:
Два варианта:
- Два варианта:
-- передаём и рисуем;
-- передаём и рисуем недоступным;
- Два варианта:
-- передаём и не рисуем;
-- передаём и не рисуем (но по-другому).
Я тут логики в упор не вижу. Но у меня есть вариант - забить нафиг на поиски логики в его коде, а тупо реализовать как он хочет. Но реализовать тупо на нетупом фреймворке может потребовать весьма нетупых усилий.
Нафига делать три варианта недоступности компонента? Не проще тогда уж рисовать и не рисовать его?
Ну это вроде очевидно:
Disabled - элемент виден, но неактивен
Hidden - элемент не виден, но для него зарезервировано место.
Collapsed - элемент не виден и его место "свернуто"
Вобщем, как выглядит моя обёртка (часть кода) над кастомным базовым типом строки StringDataItem Data
public enum VisibilityEnum { Enabled, Disabled, Hidden, Collapsed, } public class InputTextComponent : ComponentBase { [Parameter] public StringDataItem Data { get; set; } // custom string data type string Value { get => Data.Value; // I can read the value only through this property... set => Data.SetValue(value); // and set it only through this methode. } bool Disabled => Data.VisibleStyle == VisibilityEnum.Disabled; // used with "disabled" HTML attribute string Visibility => Data.VisibleStyle switch { VisibilityEnum.Collapsed => "collapse", // Bootstrap style class VisibilityEnum.Hidden => "invisible", // Bootstrap style class _ => string.Empty, }; }
И как я использую это в разметке для своего строкового компонента для ввода (часть кода)
<input type="text" @bind="Value" disabled="@Disabled" class="@Visibility" />
И как могло бы выглядеть, не будь этих извращений - два варианта с Collapsed. Я уже не говорю о том, что без этих извращений вообще бы не нужно было свой компонент делать, а сразу использовать готовые из Блейзор и его валидацию для форм.
public class InputTextComponent : ComponentBase { [Parameter] public string Data { get; set; } [Parameter] bool Disabled { get; set; } [Parameter] string Collapsed { get; set; }; [Parameter] bool Collapsed2 { get; set; } } <input type="text" @bind="Data" disabled="@Disabled" class="@Collapsed" /> if(!Collapsed2) { <input type="text" @bind="Data" disabled="@Disabled"/> }
Знаю. Но в Блейзор гарантирон умный подход к этому делу - раздел "Special cases".
Единственное, что в Блейзоре пока нельзя или сложно-костыльно сделать - также классы стилей добавлять, как атрибуты. И ладно бы просто перечислять в атрибуте class эти классы, типа
class="@ButtonCss @ButtonPrimaryCss"
но там ещё заморочки со встроенными стилями всяких InputBase-элементов, которые надо конкатенировать с вот такими своими стилями. Но вроде если приписать к какому-нибудь InputText стилевой класс таким образом - работает. Я до конца пока не понял - конкатенируются ли стили из свойства CssClass и мои собственные, добавленные способом выше.
Всё больше и больше странностей. Вот на форме есть кнопка подтверждения ввода логина и пароля. Логин, пароль, команда подтверждения - всё это его (изобретателя своего фреймворка с кастомными базовыми типами) собственные типы - два кастомных базовых и один - команда, которая тоже от такого типа унаследована. Как я говорил, суть всех этих типов - они вроде как сами управляются внутренним кодом. Но! У них куча делегатов, которые нужно все наприсвоить, чтобы они управлялись! Т.е. они конечно внутри управляются, но логику надо дать им снаружи!
Далее, чтобы определить, например, состояние кнопки (доступна, недоступна) и присвоить соответствующий стиль, нужно дать этой кнопке делегат, в логике которого анализируется состояние других кастомных типов (логина и пароля) - установлены они или нет. И если установлены - то кнопка переключит себя в состояние "доступно"... А нельзя туда-сюда не гонять логику, а оставить её всю на уровне модели для формы залогинивания? Я ведь и так на уровне модели формы определяю эту логику - зачем мне её передавать кнопке, чтобы она своё состояние поменяла? Модель формы и поменяет.
А, ещё немного запутаннее. Мало установить делегат, который определит состояние кнопки. Я же ещё и выполнить должен его! А как выполнить? А у этой кнопки (точнее, у кастомного объекта команды для этой кнопки) есть спец метод "Установить текущий стиль". Этот метод просто вызывает установленный делегат.
Т.е. я из формы беру объект команды кнопки, устанавливаю этой команде делегаты (по стилю, ещё много какие), а затем вызываю эти делегаты спецметодом. Т.е. всё управление кнопкой делается снаружи. А нафига тогда тащить эту логику в кнопку, нафига кнопке знать, как её валидируют, ставят ей стили и прочее?
У него на каждый такой кастомный базовый тип по хелперу для рисования HTML-тегов сделано. Т.е. в формах он не разные там < input > использует, а свои кастомные хелперы на каждое значение. И все эти хелперы ещё и сохраняют своё состояние - т.е. банально всё содержимое его кастомного базового типа сохраняется в хранилище, чтобы пережить HTTP-сессию... Может, из-за этого весь сыр-бор? Ну типа на форме компоненты меняют своё значение, обновляются, но всё происходит через HTTP запросы, которые не помнят состояния. И он придумал, как для каждого значения сохранить это состояние. Но это же бред - такая модель реализуется на MVVM фреймворках типа Angular или ещё каких, с частничным обновлением UI через ajax (ну или в Блейзор такое с поддержкой состояний из коробки идёт), но уж точно не требует кастомных базовых типов. А человек просто написал свой фреймворк.
И чего я пока ещё не понял - а нахрена два разных гуя иметь - на ASP.NET MVC и Blazor? Если уж переписываем, то на какой-то один, и не привязываемся одну платформу к ограничениям другой через свои мудрёные "универсальные" базовые типы и модельки. Вот есть логика в старом приложении - я её вытаскиваю и привязываю к новому гую. Зачем мне в вашу трясину с ASP.NET MVC лезть и разбираться в ваших извращениях с состояниями?.. Надо бы задать этот вопрос. Самый прикол будет, если там какая-то мутная схема, мало связанная с быстрым успешным решением задачи, а моя часть - подпевать и не отсвечивать о явных нестыковках. Но прямо об этом никто не говорит. Бывает такое? Вот, например, Мурр участвовал в подобных проектах?
Да я уже пробовал спрашивать, зачем мол ваши типы использовать. А мне он ответил что-то типа - а для привязок (что там в ASP.NET MVC за сложности с привязками, что надо что-то кастомное городить?) и для разных кастомных валидаторов, типа проверки наличия в БД. Ну и ещё у него в его типах поддержка состояния через какое-то хранилище, которое переживает HTTP сессии. Ну и чтобы бизнес-логику отделить от представления.
Так в Блейзор привязки из коробки идут, как и поддержка состояния. Проблемы с кастомной валидацией не вижу. Как и с изоляцией бизнес-логики. В упор не вижу, зачем мне его запутанный фреймворк. Но мне намекают, что надо делать, что требует заказчик, а не самодельничать. Сказали сделать с использованием его кастомных типов и подходов - делай. Я решил, что попробую по-ихнему реализовать сначала, потом покажу, что их типы применительно к Блейзор не решаеют никаких задач, а лишь усложняют всё.
А не напомните - в ASP.NET MVC никаких привязок нет? Насколько помню, там при формировании разметки вы расставляете элементы, в которые вставляете данные из модели, но в обратную сторону если модель нужно обновить - только через HTML-запрос с параметрами. Так? Т.е. ничего подобного двусторонним привязкам WPF или Blazor нет?
Если так, то пожалуй становится понятно, почему такие навороты. Ещё и попытка поддержать состояния своих "контролов". Всё это в Блейзор просто не нужно, т.к. есть из коробки. Надо всё же попробовать их убедить, а то они не знают, как работает Блейзор, и навязывают свои костыли, а я долго не мог понять, что за тайная логика за этими костылями стоит, что нужно обязательно ей следовать.
А не напомните
Всё что помню - фигово было
https://www.tutorialsteacher.com/mvc/model-binding-in-asp....
Так это не байндинг. Я, кажется, вспомнил - в ASP.NET MVC по шаблонам роутинга вы парсите полученную HTTP-строку адреса с параметрами, передаёте её в контроллер, где эти параметры мапятся на параметры контроллера, а контроллер затем уже использует эти параметры для отдачи их модели или ещё как. В Блейзор же именно привязки - большая часть работы по маппингу данных между слоями проходит под капотом, а вы лишь указываете, что к чему привязывать.
Вобщем, кажется, я понял - чел изобрёл свой statefull фреймворк на базе stateless ASP.NET MVC. Отсюда все эти кастомные типы, кастомные тег-хелперы с поддержкой состояний и прочий бред. Я щас пытаюсь Блейзор натянуть на этот его подход - вот один в один у меня состояние. Но чтобы убедить их, что у них какой-то лажовый подход, нужно эту лажу попытаться сделать и показать им, какой бред получился. Без этого что-то они не догоняют.