D&D и ASP Core.  Начало.⁠⁠

Форму сабмитить нужно тогда, когда она уже полностью заполнена. До этого вы ajax-ом на каждое change-событие предыдущего select подгребаете порцию данных, под которые динамически создаете select/options и заполняете их значения из прешедшего json-ответа. И так до тех пор, пока вся форма не будет заполнена. Потом раздисейблите submit-кнопку и юзер сможет отправить форму.

как обработать возвращаемый запрос так, чтобы он изменил View

В случае асинхронного запроса вы должны самостоятельно перестраивать UI.

При синхронном запросе просто загружается другая страница.

Контроллер делает Return View("ViewName", Model) - как это обработать аяксом я без понятия.

Вы делаете View(), а не Json, поэтому получаете готовый HTML. Вставляйте его туда, куда хотите. Что-то вроде document.getElementById('result').innerHTML = response;

ЗЫ А вообще - попробуйте сначала без аякса вообще, а потом с ним. Смешивать лапшу без понимания - такое обучение может затянуться надолго (=

как обработать возвращаемый запрос так, чтобы он изменил View

В случае асинхронного запроса вы должны самостоятельно перестраивать UI.

При синхронном запросе просто загружается другая страница.

Контроллер делает Return View("ViewName", Model) - как это обработать аяксом я без понятия.

Вы делаете View(), а не Json, поэтому получаете готовый HTML. Вставляйте его туда, куда хотите. Что-то вроде document.getElementById('result').innerHTML = response;

ЗЫ А вообще - попробуйте сначала без аякса вообще, а потом с ним. Смешивать лапшу без понимания - такое обучение может затянуться надолго (=

Вы синхронный и асинхронный запрос делаете? Но почему не одним из?

Ну, то есть он парсит импорты и просто собирает тела модулей в обычные крокфордовские "модули" в один файл в нужном порядке.

как работает SRC в скрипт тегах?

Либо src, либо скрипт в теле. Не смешивать.

этот скрипт переопределяет событие - так?

Можно повесить обработчик, который отменяет событие. Это не переопределение, а паттерн наблюдатель (observer).

нужно ловить событие submit, а не click: $(...).on('submit', function(e){ e.preventDefault(); ... });

нужно ловить событие submit, а не click: $(...).on('submit', function(e){ e.preventDefault(); ... });

Да, по щелчку по кнопке submit браузер просто делает синхронный запрос на сервер (с перезагрузкой страницы). В отличиt от простой ссылки, форма умеет делать HTTP-запросы методами, отличными от GET и передавать ввод пользователя (инпуты, селекты, textarea, чекнутые чекбоксы и радиобаттоны, файлы и т.п., хоть все и сразу).

Для этого не нужно вообще никакого JS и вешать обработчики (как у вас onsubmit и прочее), это происходит автоматически средствами браузера. Достаточно лишь указать подходящй аргументам экшна name для инпутов, благодаря которым model binder создаст нужные обекты-аргументы.

Если вы ходите асинхронный запрос (аякс, без перезагрузки страницы), то форма как таковая не нужна - полетит то, чем вы зарядите вызов функции (ну те же $.get/$.post/$.ajax). Но для семантичности форму можно оставить, но повесить на submit-кнопку обработчик, который первым делом будет отменять отправку формы (т.е. действие кнопки по умолчанию - event.preventDefault(); ), затем собирать данные из контролов и отправлять запрос на сервер и обрабатывать ответ, перестраивая интерфейс.

Да, по щелчку по кнопке submit браузер просто делает синхронный запрос на сервер (с перезагрузкой страницы). В отличиt от простой ссылки, форма умеет делать HTTP-запросы методами, отличными от GET и передавать ввод пользователя (инпуты, селекты, textarea, чекнутые чекбоксы и радиобаттоны, файлы и т.п., хоть все и сразу).

Для этого не нужно вообще никакого JS и вешать обработчики (как у вас onsubmit и прочее), это происходит автоматически средствами браузера. Достаточно лишь указать подходящй аргументам экшна name для инпутов, благодаря которым model binder создаст нужные обекты-аргументы.

Если вы ходите асинхронный запрос (аякс, без перезагрузки страницы), то форма как таковая не нужна - полетит то, чем вы зарядите вызов функции (ну те же $.get/$.post/$.ajax). Но для семантичности форму можно оставить, но повесить на submit-кнопку обработчик, который первым делом будет отменять отправку формы (т.е. действие кнопки по умолчанию - event.preventDefault(); ), затем собирать данные из контролов и отправлять запрос на сервер и обрабатывать ответ, перестраивая интерфейс.

Избыточная выборка из БД - зло. Избыточные данные на клиенте - зло в квадрате. Но ajax и ленивая подгрузка данных/пейджинг усложняют архитектуру, а то и вообще UX ("бесконечный скролл" в фотоальбомах - идеальный пример зла). Нужно как-то балансировать (=

Под избыточностью стоит понимать данные, большая часть которых скорее всего пользователю не понадобится.

Ну, значит, ищет первый подходящий роут. Если роуты задавать в Startup.Configure, то там имеет значение порядок добавления роута в коллекцию (более специфичные маршруты нужно вставлять раньше), а как это дело в атрибутах обстоит - пока не сталкивался, нужно будет вчитаться в документацию.

Ну, значит, ищет первый подходящий роут. Если роуты задавать в Startup.Configure, то там имеет значение порядок добавления роута в коллекцию (более специфичные маршруты нужно вставлять раньше), а как это дело в атрибутах обстоит - пока не сталкивался, нужно будет вчитаться в документацию.

будет приоритетней чем

Это неоднозначность, роуты конфликтуют из-за "?". Мне кажется, что из-за этого должна будет ошибка. Будь вы роутером, на какой стул сядите роут пойдете, если юзер попросит Character/Create/ ? Юзер забыл указать RaceSelect или не собирался?

Я сделал нечто подобное, Get на аяксе(jquery синтаксис это просто жопа какая-то).

Придется попривыкнуть) Все же API jQ проще, чем родное браузерное.

Только вы результат никак не ловите из запроса. Нужен либо явный коллбэк передавать в функции get/ajax, либо работать с промисами (как в моем примере). https://api.jquery.com/jquery.get/

Вы там еще хитро строите Url на JS, но я бы советовал генерить это статически через Razor и класс Url. Они умеют самостоятельно строить ссылкы по роутам и исключают возможные проблемы при отображении контента из iframe.

Что вообще такое JSON - js object notation - что он из себя представляет?

Формат организации текстовых данных, который представляет из себя валидный литерал объекта JavaScript (обратное не всегда верно). Подробности - на википедии.

json(model) - тут можно поподробней?

Можно - https://metanit.com/sharp/aspnet5/5.4.php

ASP_NET Core умеет автоматически сериализовать сишарповые объекты в строку в json-формате. Делается это функцией:

JsonResult Controller.Json(object).

это же гавнокодище

Вы всегда можете написать свою/расширить дефолтную имплементацию фабрики контроллеров и сделать няшно (=

С точки зрения семантики HTTP это нормально, ибо роут "документа" один и тот же (опциональные параметры сюда не входят). Если вы хотите сделать действительно разные ресурсы (/character/create и /character/create/5 или, там, /character/create/race=5), нужно отразить это в его роуте специальным сегментом, как я уже говорил.

Я понял о чем вы. Да, тут лучше ajax-запрос, но который возвращает не View с разметкой (хотя это тоже может быть полезно для подгрузки очередного шага какого-нибудь виззарда), а json.

То есть в контроллере теперь у вас не View(model), а:

return Json(model);

Тогда на клиенте это запросим (с помощью jQuery):

const raceId = 3; // selected by user

const URL = '@Url.Action("Create", "Character")';

$.get(URL, { race: raceId })

    .done(function (response){

        //use json data

});

боюсь что ViewModel я не обладаю

Это был пример "на вырост", тот же принцип будет справедлив для экшна:

[HttpPost] public IActionResult Create(IDictionary<string, int> skillValues)

и инпутов с именами

skillValues[mykey]

.

при таком виде запроса, я все равно попадаю на чертов первый Get

Первый экшн у вас такой же подходящий, как и второй, ибо вы используете опциональные GET-параметры. Если бы там был кастомный роут (вроде {controller}/{action}/{raceselect} ) или отличался HTTP-метод, то всё разрулилось бы. Подробнее можно почитать здесь: (https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ro...)

Для достижения вашей конкретной цели попробуйте объединить экшны в один:

[HttpGet] public IActionResult CreateCharacter(int? RaceSelect) {

    if (RaceSelect.HasValue) {...}

    else {...}

}

Вообще, GET-запросы не должны ничего менять в системе, а POST-запросы (которые обычно создают сущности) не должны иметь GET-параметры, вся информация в них должна передаваться в теле запроса.

Но если вам необходимо GET-запросом просто отобразить форму (вернуть View), с которой потом будет POST-запрос в отдельный метод, то это вполне допустимо. С дефолтным роутом будет вроде такого:

public class CharacterController {

    [HttpGet] // GET: /Character/Create/?race=5

    public IActionResult Create(int race) {

        var model = new CharacterModel(race);

        return View(model);

    }

    [HttpPost] // POST: /Character/Create/

    public IActionResult Create(CharacterModel newCharacter) {

        if (ModelState.IsValid) {

            _repository.Save(newCharacter);

            return RedirectToAction("index");

        } else {

            return View("Create", newCharacter);

        }

    }

}

только как его потом раскрыть на стороне сервака?

Вот тут (https://docs.microsoft.com/en-us/aspnet/core/mvc/models/mode...) написано:

Model binding looks for the pattern parameter_name.property_name to bind values to properties. If it doesn't find matching values of this form, it will attempt to bind using just the property name. For those types such as Collection types, model binding looks for matches to parameter_name[index] or just [index]. Model binding treats Dictionary types similarly, asking for parameter_name[key] or just [key], as long as the keys are simple types. Keys that are supported match the field names HTML

То есть, например, если юзеру покажете форму:

<form asp-action="Create" asp-controller="Character" method="post">

    <input type="number" name="newCharacter.skillValues[power]" required />

    <input type="number" name="newCharacter.skillValues[agility]" required />

    <input type="number" name="newCharacter.skillValues[speed]" required />

    <button type="submit">Save</button>

</form>

То в контроллере принимаете:

...

[HttpPost]

public IActionResult Create(CharacterModel newCharacter) {...}

...

Где вью-модель:

public class CharacterModel {

    public IDictionary<string, int> skillValues { get; set; }

}

в целом я хорошо тут ориентируюсь.

Разумеется, пока тут 3,5 сущности) Когда их станет больше на порядок, это станет болью, но замечено будет только тогда, когда будет слишком поздно распутывать всю лапшу.

Могу посоветовать неплохую книжка Адама Фримана (https://smarly.net/pro-asp-net-mvc-4), которая неплохо демонстрирует основы трехслойной архитектуры, IoC/DI и TDD.

Кому как удобнее, я русскими не пользуюсь

Хм.. сам в таком же положении. Недавно по работе начал Асп.нет кор. И к днд приглядываюсь в качестве идей для домашнего проекта. Если нужна помощь и поддержка - могу влиться)

А что именно тебе должны сказать при выборе дварфа? Классовые абилки? Недостатки? Или что в компании в эльфийском лесу это будет не совсем уместный персонаж?

Зачем вы добавляете суффиксы типов перечислений (...Enum)?

Да и разбивать по каталогам/неймспейсам таким образом стоит ли?

Вам, как программисту, важна абстракция. Сегодня это Enum, а завтра IDictionary, что потребует перемещения файлов, перетряхивания кучи кодобазы без весомого обоснования. Группировать лучше по слоям и логической общности.

Где сайт то сам ?

А чем тебе не угодил билдер orcpub2, например?

Или дело именно в создании какой-то программы в новой для себя среде?

А чем тебе не угодил билдер orcpub2, например?

Или дело именно в создании какой-то программы в новой для себя среде?