Ну хз, резиновость мне не очень нравится.

не используй CodeBehind

Но жить можно.

не знаю, есть что-то лучше qt для кроссплатформенных гуев?

используй MVVM

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

Это и правда нехорошо, и с этим нужно бороться.

используй MVVM

Это кому?

пока лучше Qt для кроссплатформы ничего стабильного и готового нет

Это кому?

использующему code behind

электрон)

Ясно

он объективно хуже Qt

электрон этот

он объективно хуже Qt

Смотря по каким характеристикам ты сравниваешь.

зато жс-макак нанять - нехрен делать, а С++ никто не знает. Скоро поколение которое в нем шарит вымрет

Это и правда нехорошо, и с этим нужно бороться.

Всмысле? Ты объявляешь, к примеру, ListView в верстке. Переменная, которая содержит это ListView неявно появляется у тебя в исходнике.

виртуализацию списков в него уже завезли?

Всмысле? Ты объявляешь, к примеру, ListView в верстке. Переменная, которая содержит это ListView неявно появляется у тебя в исходнике.

используй MVVM

Всмысле? Ты объявляешь, к примеру, ListView в верстке. Переменная, которая содержит это ListView неявно появляется у тебя в исходнике.

А для чего тебе там "переменная"?

зато жс-макак нанять - нехрен делать, а С++ никто не знает. Скоро поколение которое в нем шарит вымрет

ой, как будто там какой-то бешеный С++ я тебя умоляю

А для чего тебе там "переменная"?

Ну, к примеру, чтобы данные подгрузить в список.

С++ в Qt на C# больше похож, чем на С++

Всмысле? Ты объявляешь, к примеру, ListView в верстке. Переменная, которая содержит это ListView неявно появляется у тебя в исходнике.

+ она появляется только в исходнике, который ты в 95% случаев не редактируешь

Ну, к примеру, чтобы данные подгрузить в список.

А данные в списке разве не из вьюмодели подгружаются автоматом?

бешеный - не бешеный, а людей, способных не отстрелить себе ногу при управлении памятью ты найди ещё

Страшная штука.

ой, как будто там какой-то бешеный С++ я тебя умоляю

небешенный, но С++ программистов на порядок меньше жс-еров. Ну и лично мой опыт показывает, что то, что ЖС макака сделает за неделю ГУЙ, команда из С++ программистов будет месяц писать на кутэ

сейчас кругом макаки с питонами и руби

А данные в списке разве не из вьюмодели подгружаются автоматом?

Возможно. Я пока первые шаги в этом делаю. Но мне как-то не особо нравятся двусторонние биндинги, особенно, когда данные ридонли.

у людей мозг атрофируется постепенно

бешеный - не бешеный, а людей, способных не отстрелить себе ногу при управлении памятью ты найди ещё

так там и не нужно памятью управлять. Qt всё за тебя делает, если следовать их иерархической системе объектов

Возможно. Я пока первые шаги в этом делаю. Но мне как-то не особо нравятся двусторонние биндинги, особенно, когда данные ридонли.

А ты не делай двусторонних биндингов на ридонли-данные

так там и не нужно памятью управлять. Qt всё за тебя делает, если следовать их иерархической системе объектов

ты недооцениваешь тупость современных разработчиков

@XaveScor, тут народ не шутит, изучай MVVM. Ты не зря агришься на кодбехайнд, это правильно. В хорошем приложении им почти не пользуются, и код там не пишут.

(ну разве что если контрол делаешь, и то для композитного контрола чаще всего можно без кодбехайнда)

@XaveScor, тут народ не шутит, изучай MVVM. Ты не зря агришься на кодбехайнд, это правильно. В хорошем приложении им почти не пользуются, и код там не пишут.

Без проблем. Уже смотрю.

@XaveScor, тут народ не шутит, изучай MVVM. Ты не зря агришься на кодбехайнд, это правильно. В хорошем приложении им почти не пользуются, и код там не пишут.

Так только ты и советовал мввм))

а, тьфу. это Никита советовал

используй MVVM

Egor ↑

Используй MVVM, Люк

Никита у нас тут верховный UI-иерарх, его советы стоит слушать.

Т.е. тупые вопросы по xaml ему?)

ага и в лс

кодирует от кодбехайнда недорого

Ничо плохого не вижу в "тупых" вопросах в чате. Есть вопрос — задаёшь вопрос.

Прошу прощения, что завёл этот холивар по языкам, фреймворкам, тулкитам и гуям ?

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

Ну, простая задача: вывести эпизоды подкаста в ListView.

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

двачую

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

Я с этим согласен, но считаю, что такого кода должен быть минимум. Бывает, что не всё можно просунуть в MVVM, когда работаешь со сторонними контролами, и тогда приходится работать с кодбехайндом. Этого не стоит бояться, но и злоупотреблять не нужно.

Я пока сдеал жерез ListView.Items.Add, но это попахивает, имхо.

Я с этим согласен, но считаю, что такого кода должен быть минимум. Бывает, что не всё можно просунуть в MVVM, когда работаешь со сторонними контролами, и тогда приходится работать с кодбехайндом. Этого не стоит бояться, но и злоупотреблять не нужно.

Зачем

Я с этим согласен, но считаю, что такого кода должен быть минимум. Бывает, что не всё можно просунуть в MVVM, когда работаешь со сторонними контролами, и тогда приходится работать с кодбехайндом. Этого не стоит бояться, но и злоупотреблять не нужно.

согласен

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

обычно это всё можно на behavior'ах закодить

Пишешь ViewModel для этого контрола Потом наследуешься от контрола и припиливаешь ему нужные свойства

обычно это всё можно на behavior'ах закодить

можно

Ну, простая задача: вывести эпизоды подкаста в ListView.

Если совсем грубо, то ты биндишь свой ListView (кстати, что это такое?) на модель, в модели держишь ObservableCollection, и изменение коллекции триггерит обновление представления.

но не всегда

Если совсем грубо, то ты биндишь свой ListView (кстати, что это такое?) на модель, в модели держишь ObservableCollection, и изменение коллекции триггерит обновление представления.

*что это такое — в смысле, из какого тулкита? WPF, Xamarin Forms, ещё что-то?

*что это такое — в смысле, из какого тулкита? WPF, Xamarin Forms, ещё что-то?

uwp

но согласись, если у тебя в codebehind 500 строк кода, и это не рисующий сам себя контрол

то что-то не так

Да.

но согласись, если у тебя в codebehind 500 строк кода, и это не рисующий сам себя контрол

ясен хрен )

Нет.

МВВМ - это противречит методологии hyak-hyak driven development уменьшает time to market

*увеличивает

Возможно. Я пока первые шаги в этом делаю. Но мне как-то не особо нравятся двусторонние биндинги, особенно, когда данные ридонли.

Двусторонние биндинги не нужны для ридонли данных

Тем более с листвью

МВВМ - это противречит методологии hyak-hyak driven development уменьшает time to market

Я тимлид. Увеличивать time to market — это моя работа.

Двусторонние биндинги не нужны для ридонли данных

Спасибо, это очевидно)

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

Что ты хочешь сделать, опиши подробнее, желательно с примерами кода

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

за фиксед прайс

Что ты хочешь сделать, опиши подробнее, желательно с примерами кода

Пока ничего, просто поделился отвращением. Конкретной проблемы нет. Копаю UWP пока только. Опыт есть только с бекенд разработкой.

МВВМ - это противречит методологии hyak-hyak driven development уменьшает time to market

Зависит от размера приложения же Если оно очень большое и без мввм, то начинаешь во всём путаться

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

но бехэвиоры я вот например редко делаю

мифический рост приложения

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

с чем вообще связан тот факт, что на фронтэнд-стеке творится кромешный ад абсолютно везде - что в десктопе, что в мобильных приложениях, что в вебе?

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

с чем вообще связан тот факт, что на фронтэнд-стеке творится кромешный ад абсолютно везде - что в десктопе, что в мобильных приложениях, что в вебе?

исторически сложилось

исторически сложилось

что-то много совпадений для исторического сложения

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

как связан хайлоад и мввм? )

как связан хайлоад и мввм? )

подходы/методологии

Кстати господа

Как вы реализуете мввм в своих проектах?

я не считаю что мввм - оверкил даже для тулзы которую будут юзать 2 человека и они уверяют тебя что изменять эту тулзу не надо будет потом

я последнее время без МВВМ делаю всё. Ну или вьюмоделью делаю сам кодбехайнд

Как вы реализуете мввм в своих проектах?

у нас есть базовые классы для mvvm

базовая сборка так сказать

там всё что нужно прям - конверторы, baseviewmodel и всё такое

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

Мы всегда так делаем, и это всегда себя оправдывает.

Всегда, Карл.

громоздко и страшно: private int _someProperty; public SomeProperty { get => _someProperty; set => SetField(ref _someProperty, value, () => SomeProperty); } или коротко и ясно (☺️): public ObservableProperty<int> SomeProperty { get; }

я последнее время без МВВМ делаю всё. Ну или вьюмоделью делаю сам кодбехайнд

хотелось бы посмотреть на твои проекты

(ну, разумеется, сроки сразу с заказчиком согласуются, и он понимает, что хуяк-хуяк это не к нам. Остаются только серьёзные заказчики, с ними и отношения проще строить)