ivan-lev, я наверное не так выразился. проверить значение на пустоту не так и сложно, но я просто ширше думаю (или ширей?) эту же штуку можно вообще на валидацию полей прикрутить. Например сравнивать поля "пароль" и "пароль еще раз" -- как пример.
надо будет как-нибудь заморочиться написать такой велосипедище.
Если задач будет сыпаться мало, то напишу
Magwasha, тогда смотрите в сторону вебасиста. там всё это есть
ivan-lev, Textarea, select, input.сheckbox input.radio. input.file и т.д. забыли
Если бы всё было так просто, мы бы давно их уже всех переловили (с) Жеглов...
На самом деле проще к тем полям, которые требуют валидации добавить дата-аттрибут data-validation-rules="required|matches[field_to_compare_name]"
а дальше пробежаться по всем полям с этим аттрибутом.
но это вот уже не тривиальная задачка. так как методика проверки на заполненность для select и textarea, разные. (это как пример)
Magwasha, Поверьте, на такое кол-во товаров, такое кол-во свистелок и сопелок не нужно совем. Пойдет любой магазин, хоть webasyst/shop-script
в данном случе не надо заморачиваться, чтоб всё и сразу.
сначала надо запустить ИМ и добиться от него более-менее адекватных показателей по обороту и прибыли, а потому уже лезть в сторону CRM и т.д.
Задача простая, но геморная. вернее как, если мы делаем универсальный обработчик, независящий от типа и кол-ва полей, то это придется подумать, а если мы привязываемся к конкретным полям, то всё гораздо проще.
по онсабмит
устанавливаем флаг "сабмит разрешен" в true
смотрим заполнено/не заполнено поле, если заполнено, ничего не делаем, если не заполнено, выставляем флаг в false
[...] повторяем n раз (по кол-ву полей)
возвращаем состояние флага "сабмит разрешен" (true|false)
вот и вся логика
Как показывает практика. Индексируется. Но без гарантии. Вообще все поисковики уже давно обзавелись хорошей поддержкой яваскриптов.
offtop
ArbNet, зачем вы используете деприкейтнутый еще со времен html3.2 тэг <xmp> вместо <pre> ?
ArbNet, старайтесь так никогда не делать иначе потом задолбаетесь что-то добавлять или убирать в случае необходимости.
самый оптимальный результат, это повесить обработчик с учетом дерева
$('body form').on('change', 'input[name="animals2"]', function(){ /*code here*/ });
такая конструкция позволяет перехватывать даже динамически-создаваемые элементы
а дальше параметры задавать или через value или на худой конец через data-аттрибут.---------- Добавлено 05.02.2020 в 14:48 ----------зы.
и еще... не надо говнокода. убирайте значения аттрибутов в кавычки
возьмите за правило писать
<input name="animals2" type="radio" data-value="3">
<input name=animals2 type=radio data-value=3>
иначе однажы, когда нужно будет добавить какой-нибудь текст с пробелом в аттрибут, вы огребете немало проблем
время генерации страницы никак не зависит от сторонних скриптов.
Время генерации страницы, зависит только от ресурсов и настроек сервера.
Генерация ХТМЛ очень сильно скачет.
от 370мс до 7 секунд. что может говорить только о том, что скорее всего проблемы с выделением памяти процессу или базе. Надо смотреть логи и конфиги.
Хотите прикол. У нас есть сайт, который по статистике, посещается в основном с xp и ie разной степени древности. Сайт медицинской тематики.
А проблема в том, что софтина у медиков, все их базы в поликлиниках, работают исключительно под XP. Причем это приказ по министерству. То-есть они не имеют права поставить десятку, виртуальную машину и лазить из под нормальной среды, а в прогах работать на этом старом д***ме.
Вот они в чем работают, в том в интернет и лазают. А так как у нас это большой медицинский справочник для специалистов, то лазают они туда постоянно.
Поэтому я и говорю, что надо в первую очередь опираться на статистику.