А без паблик сеттера, но с паблик методом установки - необычное.

------

Поработал бы с Жабой - было бы обычным...

Во, ещё нашёл - он обрабатывает это перечисление двумя 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"/>
}

disabled="@Disabled"

а вот тут тебя ждёт сюрприз ХТМЛ

Для браузера Disabled=false это то же самое что просто 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. Отсюда все эти кастомные типы, кастомные тег-хелперы с поддержкой состояний и прочий бред. Я щас пытаюсь Блейзор натянуть на этот его подход - вот один в один у меня состояние. Но чтобы убедить их, что у них какой-то лажовый подход, нужно эту лажу попытаться сделать и показать им, какой бред получился. Без этого что-то они не догоняют.