.NET und C# ohne Web?
Ну правильно, в JSON есть поля{"AAA":{...},"BBB":{...},"CCC":{...}}
Проблема в том, что AAA обязательно должно присутствовать и значение должно быть числовое, BBB - опциональное поле и тип строка, но не больше 100 символов, CCC - обязательное поле и перечисление, а есть еще DDD - bool и еще 100 других полей. Можно конечно все это описать в PDF, но кто их читает? ;) Я уж не говорю о контроле, т.к. в какой-то момент команда A решает, что поле BBB теперь обязательное, рассылает всем PDF и валидуруй каждое поле в кучном режиме :)
это на сколько идиотами должны быть разрабы в командах, если они не договорились, что будет лежать в форматах для AAA, BBB, CCC? Тут валидация адекватности разрабов важна, а не городить "прогграммирование ради программирования".
Ну вот мы например фирма в Германии даем спецификацию фирме в Японии. Мы друг с другом вообще не разговариваем, в лучшем случае диалог есть при посредничестве клиента. В хорошем варианте, клиент передаст нам е-мыл другой конторы и мы сможем запросить их спеки и отправить свои. Но обычно мы даем спеки клиенту, а клиент пересылает их дальше. Так что никаких договоренностей в большинстве случаев нет.
Да и в пределах одной фирмы договоренности есть далеко не всегда. Кто-то просто предоставляет интерфейс и все.
Все так и не понимаю для чего валидация нужна, кроме надуманных случаев когда команды друг другу создают проблемы. Может я все-таки что-то упустил и есть какой-то реально нужный пример?
XSD файл - это контракт (в терминах C# это интерфейс) по которому общаются (программно) несвязанные меджу собой модули. Имея на руках XSD ты всегда можешь проверить соответствует ли твой код заданному контракту. Если два модуля не работают друг с другом, то всегда можно определить почему. При этом определить можно в автоматическом режиме.
-----
Уточни, плс, что именно и как ты собираешься проверять?
И второй вопрос - как именно ты собираешься сегодня написать проверку для того что тебе дадут завтра или через год или через пятилетку и в проекте исходники которого тебе не даюt?
Касательно ямл и его валидации - можно юзать чужие схемы валидации для ямла
xsd - YAML Schema Validation? - Stack Overflow
В ямле удобно хранить данные - куда как более читаемо и меньше размер. Не раз уже встречал ямл как основной формат для хранения данных довольно больших размеров (десятки килобайт).
В Unity префабы хранятся в ямл - пример части файла ниже. Представьте, как это было бы всё нечитаемо, если бы XML-тегами всё было обрамлено.
Меня, например, всегда напрягала многословность разметки в XAML (WPF, UWP, Silverlight) по сравнению с CSS. Описываешь стили там и там - в XAML какое-то бешеное накручивание специальных значков. Сделали бы описание интерфейса в Дотнете на основе ямл или хотябы джейсон.
1) В XML все эти параметры можно записать в виде аттрибутов. Я понимаю, что это не итак интересно для сравнения :)
2) В XML можно отобразить такую структуру:
<Servers>
<HttpServer name="..." ... />
<FtpServer name="..." ... />
<SomeOtherServer name="..." ... />
</Servers>
Продемонстрируй, как такая структура будет выглядеть в YAML?
Меня, например, всегда напрягала многословность разметки в XAML (WPF, UWP, Silverlight) по сравнению с CSS. Описываешь стили там и там - в XAML какое-то бешеное накручивание специальных значков. Сделали бы описание интерфейса в Дотнете на основе ямл или хотябы джейсон.
Ну вот простенький XAML:
<Grid>
<Grid.RowDefinitions>
<RowDefinition />
<RowDefinition Height="33" />
</Grid.RowDefinitions>
<TextBox Grid.Row="0" TextWrapping="Wrap" AcceptsReturn="True" Text="{Binding MessageTemplates, Converter={StaticResource ObservableCollection2StringConverter}}" />
<Grid Grid.Row="1">
<Grid.ColumnDefinitions>
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition Width="100" />
</Grid.ColumnDefinitions>
<CheckBox Grid.Column="0" Content="Convert to HEX" IsChecked="{Binding ConvertToHEX}" Margin="5" VerticalAlignment="Center" />
<CheckBox Grid.Column="1" Content="Open in Explorer" IsChecked="{Binding OpenExplorer}" Margin="5" VerticalAlignment="Center" />
<Button Grid.Column="2" Content="Generate" Command="{Binding Generate}" Margin="5" VerticalAlignment="Center" />
</Grid>
</Grid>
покажи как бы такая структура выглядела бы в YAML. Чтобы было проще, названия аттрибутов с точкой можешь считать как одно слово.
В ямле удобно хранить данные - куда как более читаемо и меньше размер.
------
Наименьший размер данных будет у файла в котором нет избыточной информации - имен полей, разделителей и т.п.
Для машины - без разницы насколько он читаемый.
А для человека в любом случае нужен подходящий инструмент. Потребовать чтобы он представлял данные в удобоваримом виде - не проблема.
как это было бы всё нечитаемо, если бы
------
Угу... вот только один моментик - ссылка небольшой ХСЛТ добавленная в ХМЛ предоставит точно такое же вью... все в рамках стандартов.
А что и куда надо добавить в твоем варианте Я не знаю.
2) В XML можно отобразить такую структуру:
<Servers> <HttpServer name="..." ... /> <FtpServer name="..." ... /> <SomeOtherServer name="..." ... /> </Servers>Продемонстрируй, как такая структура будет выглядеть в YAML?
Это зависит от того, какие объекты вы сериализуете в XML. Скорее всего, они же и в YAML прекрасно сериализуются. Тут, как я понял, коллекция серверов разных типов - значит, скорее всего, эта коллекция хранит элементы некоего базового типа, к которому приводятся унаследованные от него производные типы серверов. В YAML нельзя хранить базовые типы или инфу о конкретном типе элемента в коллекции?
Я, если что, не спец по форматам - просто мне нравится, как выглядит YAML. У XML недостаток в синтаксисе - слишком много условных значков и лишние закрывающие теги - всё это сильно снижает читаемость.
Ну вот простенький XAML:
<Grid> <Grid.RowDefinitions> <RowDefinition /> <RowDefinition Height="33" /> </Grid.RowDefinitions> <TextBox Grid.Row="0" TextWrapping="Wrap" AcceptsReturn="True" Text="{Binding MessageTemplates, Converter={StaticResource ObservableCollection2StringConverter}}" /> <Grid Grid.Row="1"> <Grid.ColumnDefinitions> <ColumnDefinition /> <ColumnDefinition /> <ColumnDefinition Width="100" /> </Grid.ColumnDefinitions> <CheckBox Grid.Column="0" Content="Convert to HEX" IsChecked="{Binding ConvertToHEX}" Margin="5" VerticalAlignment="Center" /> <CheckBox Grid.Column="1" Content="Open in Explorer" IsChecked="{Binding OpenExplorer}" Margin="5" VerticalAlignment="Center" /> <Button Grid.Column="2" Content="Generate" Command="{Binding Generate}" Margin="5" VerticalAlignment="Center" /> </Grid> </Grid>покажи как бы такая структура выглядела бы в YAML. Чтобы было проще, названия аттрибутов с точкой можешь считать как одно слово.
Я не знаю как точно - не знаком подробно с ситнаксисом YAML. Ну примерно так (очень приблизительно):
Grid
Rows:
- Row
Row
Height:33
TextBox
GridRow:0
TextWrapping:wrap
AcceptsReturn:true
Text
Binding
Path:MessageTemplates
Converter
StaticResource:ObservableCollection2StringConverter
Grid
GridRow:1
Columns:
- Column
Column
Column
Width:100
CheckBox
GridColumn:0
Content:Convert to HEX
IsChecked
Binding
Path:ConvertToHEX
Margin:5
VerticalAlignment:Center
Ну и т.д.
Насколько я понимаю, запись данных что в тегах, что в атрибутах равнозначна. Просто в атрибутах пишутся простые данные, а в тегах - сложные, составные. Но в любом случае это всё свойства представляемого объекта. Просто если данное больше не делится - является элементарным типом, то его можно в атрибут поместить. А если охота его расписать - то через вложенные теги.
В YAML нельзя хранить базовые типы или инфу о конкретном типе элемента в коллекции?
Это ты у меня спрашиваешь? :) Ты же пропагандируешь YAML. Вот и скажи ;)
Ну и т.д.
Ты же понимаешь, что 18 строк XAMLа ты перевел в 29 строк (не полностью, а полностью было бы 44 строки) на YAML? По-твоему это как-то улучшило читаемость? И тебе не кажется, что это как-то не очень соотносится с "легковестностью" YAMLа?
Это ты у меня спрашиваешь? :) Ты же пропагандируешь YAML. Вот и скажи ;)
А я думал, это мне тут объяснят - тут же типа опытные собрались. )))
Я в нём не разбираюсь, я увидел несколько раз его использование в реальных проектах, почитал, в чём некоторые отличия, но в глубину не копал.
Мне вообще как программисту в нём разбираться особо и не нужно - дайте мне сериалайзер-десериалазйер и нормальный АПИ к нему - больше мне ничего не нужно. Нафига мне лезть в чёрные коробочки, если они (если!) будут нормально работать?
Ты же понимаешь, что 18 строк XAMLа ты перевел в 29 строк (не полностью, а полностью было бы 44 строки) на YAML? По-твоему это как-то улучшило читаемость? И тебе не кажется, что это как-то не очень соотносится с "легковестностью" YAMLа?
Не в строках дело, а в объёме текста, количестве служебных значков, которые все только мешают воспринимать основную информацию. У вас в XML или XAML просто строки длинные - из каждой надо выхватить несколько кусков инфы, очистив её от служебных слов и закорючек. Ямл сразу охватываешь взглядом почти всю страницу и быстро находишь, что нужно. А XML или XAML сначала "парсишь" глазами и головой. Открывая документ XML или XAML на всего лишь одну страницу, мне проще воспользоваться полнотекстовым поиском, чтобы найту нужное слово, а в ямл проще и быстрее глазами. Это если не впадать в крайности.
XML или XAML тоже могут быть достаточно читаемыми - тогда тоже придётся много строчек использовать - каждый атрибут на новой строке. Вот у вас, например, слишком длинная строка получилась и приходится форум горизонтально прокручивать. Но просто посмотрите, сколько лишней инфы находится в типичном XML или XAML при хорошей такой иерархии вложенностей
<DockPanel.Triggers>
<EventTrigger
RoutedEvent="DockPanel.MouseEnter">
<BeginStoryboard>
<Storyboard>
<DoubleAnimation
Duration="0:0:0.100"
To="1"
Storyboard.TargetName="descriptionButton"
Storyboard.TargetProperty="Opacity" />
</Storyboard>
</BeginStoryboard>
</EventTrigger>
<EventTrigger
RoutedEvent="DockPanel.MouseLeave">
<BeginStoryboard>
<Storyboard>
<DoubleAnimation
Duration="0:0:0.100"
To="0"
Storyboard.TargetName="descriptionButton"
Storyboard.TargetProperty="Opacity" />
</Storyboard>
</BeginStoryboard>
</EventTrigger>
</DockPanel.Triggers>Блин, подсветки нет. Вот с подсветкой видно (фиолетовый цвет), что на всю кучу инфы всего несколько значений, которые важны и нужно прочитать. Полезность текста в XML или XAML где-то процентов 20-30, остальное - мусор.
Как вы сюда код вставляете с моноширинным текстом и сохранением форматирования (отступов и прочего)?
каждый атрибут на новой строке.
Это ужасно :)
Блин, подсветки нет. Вот с подсветкой видно (фиолетовый цвет), что на всю кучу инфы всего несколько значений, которые важны и нужно прочитать. Полезность текста в XML или XAML где-то процентов 20-30, остальное - мусор.
Полезность не 20-30 процентов ;) Фиолетовый - это только значения, однако имена соответствующих значений тоже важны (и они точно также есть в YAML ;) )
Вся экономия заключается в YAML
GridColumn:0
против в XML
GridColumn="0"
этономия ровно 2 символа :D
А если взять закрывающие тэги, то YAML накладывает ограничение в том, чтобы данные были вывовнены по границе объекта, к которому они принадлежат. Так что съекономили на закрывающем тэге и в 10 раз больше потратили на <TAB> :D
Ну и текстик в 44 строки не так то уж просто прочитать :)
Как вы сюда код вставляете с моноширинным текстом и сохранением форматирования (отступов и прочего)?
1) Нажимаешь кнопку "<>" (рядом с Bold)
2) пишешь текст в блоке <pre></pre>
каждый атрибут на новой строке.Это ужасно :)
Я не могу нормально читать ваши атрибуты, написанные кучей в одну строку. И когда у вас пустых строк нет между хотя бы блоками вложенностей тегов - типа коллекцию элементов RowDefinitions отделить сверху и снизу пустой строкой. Когда атрибуты каждый на своей строке, то можно и не отделать - вполне и так читаемо. Но когда всё в куче, то хотя бы пустые строки помогли бы. У вас там на экране места мало, чтоли? Я думал, уже у всех стоят минимум 2 моника на 32 дюйма хотя бы 2560х1440. ))
Но это не проблема, если есть автоформатирование при открытии файла. Открываю вашу разметку у себя - автоформат под мои требования. У всех нормальных IDE это давно идёт из коробки.
Полезность не 20-30 процентов ;) Фиолетовый - это только значения, однако имена соответствующих значений тоже важны (и они точно также есть в YAML ;) )
Das ist schon dazu gehört. Я уже прикинул имена тегов в эти 20-30%.
Ямл лучше тем, что просто пустое пространство, которое в Ямл изобилует, гораздо лучше воспринимается и не отвлекает, чем это же пространство, забитое всяким мусором.
Заметьте, как в Ямл хорошо читаются даже тексты без подсветки. В XML без подсветки чёрт ногу сломит.
Так что съекономили на закрывающем тэге и в 10 раз больше потратили на :D
Все табы проставляются автоматически, как и каретки выравниваются при переходе на новую строку - как в XML, так и в YAML. Если нужно начать новый объект и автопростановка поставила слишком много табов - убираешь табы бэкспейсом. Это происходит и в XML, и в YAML редакторах.
Ну и текстик в 44 строки не так то уж просто прочитать :)
Внимание расходуется не на количество строк, а на количество слов и символов, которые нужно "распарсить" головой.
Скука, как же повезло инглишьменам - не надо постоянно язык переключать, когда говорят о своих технологиях!
1) Нажимаешь кнопку "<>" (рядом с Bold)
2) пишешь текст в блоке <pre></pre>
Т.е. я должне вручную напечатать эти теги, да ещё как-то догадаться, что это надо сделать в режиме "<>". И всё равно подсветки не будет? "Гений ты Моцарт, и шутки у тебя гениальные." https://youtu.be/GUKdwYBi9Rs?t=184
А XML или XAML сначала "парсишь" глазами и головой.
-----
Это аккурат следует из:
Мне вообще как программисту в нём разбираться особо и не нужно
Выше Я писал - в ХМЛ достаточно втиснуть ссылку на ХСЛТишку и можно получить нужную трансформацию.
Правда чтобы это сделать... или хотя бы знать об такой возможности, об "особо и не нужно" надо забыть.
Ну что, будущее дотнета в области UI - MAUI и Blazor? Остальное можно "забывать"? Готовишься сейчас, а через годик-другой - бум вакансий по MAUI и Blazor?
.NET Multi-platform App UI (.NET MAUI)a cross-platform UI toolkit announced in May 2020 that originated as a fork of Xamarin.Forms and that can run on Android, iOS, Linux, macOS, Tizen, and Windows. .NET MAUI will run on .NET 6 and later.[25][26][27] The source code is licensed under MIT License and available on GitHub.[28]Blazora free and open-source web framework that enables developers to create Web apps using C# and HTML. Blazor Server apps are hosted on an ASP.NET Core server in ASP.NET Razor format, while Blazor WebAssembly apps are Single-page apps that are downloaded to the client's web browser before running.
https://en.wikipedia.org/wiki/List_of_.NET_libraries_and_f...
Создал консольный проект на Дотнет 5 - часть файлов конфигов на джейсоне. Только конфиг проекта на XML. Похоже, Студия тоже постепенно переезжает на джейсон. ASP.NET MVC конфиги так уже давно на нём.
XML должен умереть. Кто согласен? ))
А в Unity3D наоборот решили новый UI делать на XML,HTML-образном синтаксисе. Да что ж такое-то!..
Overview | UI Builder | 1.0.0-preview.14 (unity3d.com)
Пришло время избавиться от Angular и сэкономить миллиарды долларов / RUVDS.com company blog / Habr
Скоро до Реакта дойдут и далее по списку.