Владимир, легче распарсить файл в таблицу в БД, а потом просто скрипт написать и прогнать один раз. Это если цены нужно единоразово поменять, а не каждую неделю, например.
О да, "Чистая архитектура" для только начавшего изучать программирование будет сущим адом. Он про SOLID, паттерны-то ничего не слышал, а вы хотите, чтобы он вкусил архитектуры от старины Мартина...
1. Форма отправки файла на хранение на сервер;
2. Валидация отправленного файла на сервере (тот ли формат, есть ли нужные данные, не битые ли они и еще много чего);
3. Если валидация пройдена, то сохранение файла на сервере, создание записи по этому файлу в БД (с указанием пути, по которому лежит файл);
4. Оповещение пользователя об успехе операции.
При построении графиков обращаться к таблице с экселями, читать их как нужно, строить что нужно.
Если создаете не через интерфейс студии, а в проводнике Windows, то стоит эту паку включить (Include in project) в проект. Нажмите кнопку "показать все файлы", найдите нужные папки и включите их в свой проект.
Есть предположение, что запрос кэшируется и выполняется быстрее. SQL вроде как умеет кешировать параметризированные запросы, т.е. те, в которых изменяется только несколько однотипных параметров (в вашем случае даты). Так первый запрос должен быть медленным, остальные быстрее. Чтобы тестировать как это будет на самом деле - нужно где-то выключать кеширование запросов для текущей сессии.
Если есть доступ к БД, а он должен быть, то просто посмотрите таблицы. Скорее всего там должна быть таблица, связанная с основной таблицей пользователей. Ну и запрос напишите.
Nik Faraday, можно все вспомогательные вещи (тулбары, меню навигации и пр.) хранить в отдельном контроллере, а во всех остальных вьюшках просто вызывать построение частичного представления с передачей параметров (PartialView). Ну и соответственно все cshtml у тебя будут храниться где-то в {HelperControllerName}/Navbar.cshtml.
Лично мне хватает функционала мастер-страницы и представления: все, что должно повторяться на каждой странице, я строю на мастер-странице, а в представлении контроллера строю только что-то специфичное.
function textdown() {
let active = this.parentNode.querySelector(".elem-bot");
active.classList.toggle('active_text');
//arrow[i].classList.toggle('arrow_rotate');
}
Вы в функции textdown оббегаете весь массив. Нужно только лишь по активному элементу. Вернее будет сделать так: сначала у всех блоков отобрать классы на "показ", а затем присвоить классы на "показ" лишь активному элементу.
runapa, да, невнимательно прочитал вопрос. Ну в любом случае данные обновлять нужно ajax-запросом, а уж как отрисовывать (целиком таблицу или бежать по ней и вставлять данные в определенные ячейки) это дело каждого. Я бы отрисовывал только tbody у таблицы. Вообще зависит от того, что должна уметь таблица и как она работает с данными.
Еще стоит прояснить следующие вещи:
1. При повторном запросе изменения профиля пользователем - что делать с предыдущим изменением, если администратор не успел его проверить? (как вариант оставлять последний, оставлять все - на выбор администратору);
2. Сам пользователь может запросить отмену отправленных изменений? Он вообще видит, что его профиль будет подвергнут изменению? (флажок какой, надпись в личном кабинете и пр.)
Как вариант можно разделить профиль на что-то типа profile + info, где info будет представлять собой подтверждаемые данные. Тогда будет так: Profiles(Id, InfoId, ...) и Info (Id, ProfileId, email, fio, ..., isActual (1 - у актуальной информации, 0 - у не очень)).
Администратор при входе в админку будет строить запрос по пользователям у которых есть два и более объекта Info и как-то обрабатывать их. При подтверждении одного из Info мы подменяем InfoId у профиля на нужный, ставим признак isActual. Остальные же Info по этому профилю либо удаляем, либо помечаем как отработанные или удаленные.
Пользователь же будет подтягивать информацию по своему InfoId, но и получит возможность знать, что там по его аккаунту творится у администратора (например, кол-во ожидающих изменений можно посмотреть или еще что).
И будет постоянно что-то и где-то заблокировано. Уж луче перед самой записью в БД проверять, что запись не изменена и менять её, в ином случае сообщать пользователю, что "данные этой карточки были изменены ХХХХ сегодня в 15:49. Продолжить и затереть данные?".
margaret_murka, ну если выводит описание класса в консоль, то значит библиотека Chart.js подключилась нормально. Даже не знаю, что и посоветовать: без непосредственно кода не разобраться.
Попробуйте вызвать функцию (которую вы пишете в window.onload) напрямую из консоли. И в зависимости от того построится график или нет нужно думать дальше.
У вас прямо вот этот код выдает алерт? Просто меня смущает, что он написан прямо в json настройках графика)
Если все же алерт стоит строчкой выше (до var sex) и он работает, то проверьте загрузился ли вообще скрипт chart.js. Можете в том же алерте написать так: alert(Chart).