abberati, спасибо! Интересно.
Мне вот тоже как-то уже привычнее и комфортнее работать с Redux.
И в тоже время на Хабре и т.д. продолжают выходить статьи на тему "бросайте Redux - useConrext решит все ваши проблемы"!)
>> По идее это решение для обмена состоянием между не связанными компонентами, вроде списка товаров в корзине, который нужен и в шапке, и на конкретных страницах, и на странице любого товара, и в списке сопутствующих покупок.
Для этого сейчас можно также использовать useContext хук. Вопросов становится всё больше!..)
Мало информации даёте!
В чем макет? PS, Figma, что-то ещё?
После этого возникают вопросы:
В каких единицах указан шрифт в макете?
В каких единицах задан шрифт в вашем css?
Точно ли корректно подключился и заработал шрифт?
И, как уже советовали выше, смотрите в отладчике браузера, точно ли в браузере тот самый размер шрифта, который вы хотите видеть (не перебивается ли чем-то)?
Я думаю, что простые правила валидации валидируются ajax. А сложные уже после нажатия кнопки и запроса на сервер.
Вот меня и сбивало это, похоже. Поэтому и не отключал аякс-валидацию. А оказалось, что этот параметр немного не про то, судя по всему.
А ведь там, наверное, и аякса нет. Фреймворк генерирует JS-валидацию при создании формы, и всё.
Дмитрий, курс на Udemy.
За ссылку спасибо, пошел читать!
По поводу версий и нового.
Но ведь и про jQuery, кажется, уже больше года пишут, что он мертв, а в 70-80% боевых проектов он используется.
Про бутстрап, все давно хотят 4й, но потом оказывается, что клиенту нужна поддержка IE 10, и проект делается на 3м.
Или надо бежать от таких примеров "обратной совместимости"?
DevMan, я не уверен, что правильно понимаю Ваш вопрос, к сожалению.
Если можно, поясните, в чем неясность перспектив и в чем локальность Yii2, пожалуйста!
coderxx, тут надо искать золотую середину между тяжелой но красивой и удобной админкой CMS и каким-то осознанным внесением данных, имхо.
Для клиента, если он в состоянии, внесение данных в JSON будет минимально отличаться от внесения данных в текстовый документ. Загрузка по FTP - тоже процесс несложный. Можно ярлычков наделать, можно вообще автоматизировать.
Если же исходить из того, что нужна админка, рассчитанная на минимальный уровень и с "защитой от дурака" тогда, на мой взгляд, дорога к CMS.
Ещё вариант, кажется, уже предложили - парсинг привычных клиенту файлов, типа табличных.
Да, кстати, если загрузка по FTP пугает, можно сделать какой-то простенький интерфейс для загрузки JSON-файлов.
Напрашивается хранение пользователей в БД и какие-то действия с ними на сервере, уже отсюда мы можем говорить, что бэк вам нужен.
Чат-бот - мне кажется, отдельная тема. В формате "какого выбрать/написать" - "как прикрутить к...". Но тут я не силен, м.б. про него отдельный вопрос создать?
Какие технологии нужны для реализации такого проекта
- серверный язык программирования - PHP и Python самые популярные, на мой взгляд,
- БД на сервере - тот же MySQL, например.
Дальше возникает вопрос: работать с этим "в лоб", или использовать какие-то прослойки? С прослойками явно быстрее и удобнее. Я бы все разделил на CMS и Фреймворки. CMS, наверное, проще (например, кто-то проводил параллель "далее - далее - готово" - примерно так ставится тот же Wordpress (на PHP)). Фреймворки, наверное, требуют больше времени на изучение-погружение, но дают большую гибкость и возможности (Laraval, YII2 на PHP, Django на Python, например).
В принципе, считаю что описанный вами сайт (чат-бота пока не рассматриваю) можно сделать и на том, и на том. Наверное на основе чего-то, более похожего на ТЗ, профессионал, владеющий несколькими инструментами ответит, какой из них подойдет лучше. Но это будет с его точки зрения же!
Если говорить о том, что изучать: скорее всего PHP (имхо, применяется пока шире). Или Python. Потом к выбранному языку выбирать инструмент и изучать его. Чтобы в CMS пойи дальше работы в админке, в нее ведь тоже придется погружаться!..
зная только фронтенд
На сервере же что-то должно происходить! Значит одним фронтом не обойдетесь.
Даже при вот такой записи та же самая ошибка: