(js) унифицированный скрипт проверки данных формы
Каким путем можно решить эту задачу?
и при submit'е делать обход всех элементов и проверять наличие этого параметра и заполненность поля, но это понимает только IE
Если ты имеешь в виду нативная поддежка, то может быть, а если такой обработчик полей формы ты пишешь сам, то нифига. Будет работа везде если ты позаботишься о кроссплатформенности.
Почитай вот это: HTML_MetaForm: извлечение информации о структуре HTML-формы и ее обработка и вот это HTML_FormPersister: новый взгляд на построение форм.
Каким путем можно решить эту задачу?
Лучше хранить список имен элементов формы, которые нужно проверять.
[HTML]<script><!--
function checker(f,id,list)
{
for(var i = 0; i < list.length; i++)
{
var el = f[list];
// Обрабатываем el в зависимости от типа.
}
}
function installChecker(id,list)
{
var f = document.getElementById(id);
if(f)
f.onsubmit = function() { checker(f, id, list); };
}
--></script>
<form action="" id="form1">
...
</form>
<script><!--
installChecker('form1', ['name', 'job', ...]);
--></script>
[/HTML]
Да, спасибо. Не берусь судить о том, лучше это (чем направление, данное alekciy) или нет, но то что быстрее - это однозначно (быстрее в плане освоения решения - не нужно беспокоиться о внедрении php-решений в мой не-php проект).
alekciy, Вы упоминаете об этом уже второй раз. Для очистки совести скажу, что на стороне сервера я проверяю и кромсаю данные, как мне требуется, ибо это моя вотчина. Об этой стороне я собственно и не спрашиваю. А вот клиентская сторона - хотя и не моя задача, но тоже почему-то достается мне. Пока решение, предложенное Nixus и уже мной реализованное, всех устроило и все довольны.
http://www.jsvalidate.com/ - покрасивше, но потянет за собой prototype+scriptaculo
Ну говорил же, без AJAX тут не обойтись - проверка сразу сервером и не отходя от кассы.
1) усложнит серверный скрипт, что в конце концов может привести к появлению проблем с безопасностью
2) требует вносить изменние в уже рабочие скрипты, что не всегда желательно и возможно
3) увеличивает нагрузку на сервер
По-моему, оно того не стоит.
Автор сказал что обязательно нужен AJAX?
Я предложил варианты без AJAX-а, как первичная проверка (заполнено/число/дата...) самое-то
Я предложил варианты без AJAX-а, как первичная проверка (заполнено/число/дата...) самое-то
Нет, автор (то есть я) и не заикался об ajax, т.к. был твердо уверен в том, что ему нужен именно javascript.
А я как раз собираюсь обойтись без него. Я не сторонник применения технологий ради применения технологий, а именно так у меня с ajax'ом и получится. Тем более что главная моя цель использования js - ограничение числа походов на сервер.
AJAX это и есть JavaScript.
AJAX есть методология программирования с использованием асинхронных клиенских запрсов и можно тоже самое на VB делать. Да и без серверных скриптов далеко на AJAX не уедешь. Поэтому, позвольте не согласиться, что AJAX это и есть JavaScript.
Эта фраза эквивалентна: "ООП это и есть C++".
Это безусловно методология. Но за ней конкретный программный код, конкретный обекты. Тот же VB к браузеру ты просто так не прикрутишь. А учитывая, что про аякс стали говорить после статьи Гаррета, то в ней он как раз и указывает, что один из основных компонентов такой системы это JS. Поэтому сейчас уж так получается, говорим аякс, понимаем XMLHttpRequest объект.
A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.
Взято тут.
Даже Гаррет говорит, что AJAX это набор технологий, а не какая-то из них. Так что не соглашусь еще раз.
JavaScript есть существенный элемент при реализации методологии AJAX, но этот элемент далеко не единственный. И сопоставляь их - суть кривда.
Так что пока не было XMLHttpRequest в JS небыло и аякса. Сама технологи по хорошему называется не аяксом, это технология "асинхронного обмена данными между клиентом и сервером в фоном режими". Вот это технология, вот это может быть реализованно на разных языках. Что собсвенно и делалось наиболее продвинутыми разрабами задолго до аякса.
Но вот в браузерах появилась поддежка XMLHttpRequest (даже странно, что такую хорошую идею реализовал MS первым из всех). И используя уже известную технологию (особо это поддеркиваю) стали писать клиентские приложения. И обозвали все это дело аяксом.
Поэтому если уж мы говорим об асинхронном обмене данными с сервером, то это любой язык, а уж коль упомянули аякс, то предполагаем использование JS на клиенте для реализации этого подхода.
Если исходить из твоего принципа, что AJAX это XMLHttpRequest и JavaScript, то я скажу так: AJAX без JavaScript не возможен, а JavaScript без AJAX'а вполне. Даже в твоем базисе это утверждение весьма спорно, а если принять базис, что AJAX это методолигия асинхронного программирования, тем боле. И твоя поправка Hrew весьма не к месту была.
З.Ы.
AJAX (Asynchronous JavaScript and XML)
А насчет аякса ты видимо мой пост не понял. Я не говорю, что AJAX == JavaScript (неужели меня можно заподзрить в таком ламеризме?!??!). Ты перечитай тот пост в контексте предыдуших ;)
Я и читал пост в контксте предыдущих. Hrew сказал немного не точно, но ему, т.к. он не в теме, простительно, а вот завсегдатаю форума да еще и в теме...
Вообщем флудить можно еще долго. Предлагаю прекратить... )
Вообщем флудить можно еще долго. Предлагаю прекратить... )
Вот именно. Потому как в теме имею право на свою точку зрения. Технически обоснованную кстати, тем более в контексте данной темы.
Каждый имеет право, на свою точку зрения, это раз.
Если человек в теме, то это не гарантирует что он не ляпнет глупость, это два.
"AJAX это и есть JavaScript."
Заменим в диалоге AJAX на stdlib, а JavaScript на C++.
stdlib это и есть C++.[/QUOTE]
Заметна абсурдность утверждения?
ПП. Понизившего репутацию тут тоже приглашаю к дискусии, если есть что сказать.
Заметна абсурдность утверждения?
Сравнение не совсем корректно. Ситуация с компилируемыми языками в данном случае немного другая. Есть четкая спецификация на язык, там все создатели и обозначиют. Используемую терминологию в том числе. Парадигма-с....
А тут? Гаррет взял, да и придумал новую аббревиатуру к не новому уже понятию. А MS взяло и фактически к тому же самому придумало своё в реализации через ActiveX. Кто во что горазд... вот W3C те молодцы, хотя они всегда работали на уровне абстракций, просто взяли и описали API объекта.
Так что я не утверждаю, что жаба это аякс, а аякс это жаба и это просто синонимы. Я отлично знаю разницу между ними. Уж спецуху на XMLHttpRequest читал еще только когда она вышла в черновом варианте.
ПП. Понизившего репутацию тут тоже приглашаю к дискусии, если есть что сказать.
Ого! Интрига! :D
Я то думал это ты :) . Теперь и мне интересно.
Я о том, что ты можешь в C++ как использовать стандартную библиотеку, так и не использовать ее (использовать любую другую). Сам C++ от этого не убудет.
Так же как можешь использовать XMLHttpRequest в JavaScript, а можешь и не использовать.
Так же как можешь использовать XMLHttpRequest в JavaScript, а можешь и не использовать.
Можешь. Только асинхронный обмен с сервером через стандартный набор HTML+CSS+JavaScript ты на нормальном браузере уже не огранизуешь.
Конечно, можно привлеч к этому делу флеш (вот флекс супер) с тем же результатом. Но. Флеш на браузере отключен чаще, чем JS в силу того, что вебразработы попросту своей работой дескридитировали саму технологию.
И собственно возвращаясь к теме, о том надо ли проверять форму на сервере, безусловно надо, НО только в том случае если форму по каким то причинам не проверил JavaScript. (отключен, непрогрузился и т.п.)
Совершенно неправильный и даже вредный совет. Данные с клиента нужно на сервере проверять ВСЕГДА.
Совсем не понял о чем ты.
Так же как можешь использовать XMLHttpRequest в JavaScript, а можешь и не использовать.
Если ты организуешь асинхронку, у тебя нет выбора использовать/не_использовать. Это в С++ хочешь юзать стандартную либу, юзаешь её. Не нравиться, подключаешь к проекту любую другую нужную и на выходе (заказчику) отдаешь готовое приложение реализующее требуемый функционал.
С веб программингом так нельзя. Ты не можешь писать асинхронку и сказать, да пусть этот XMLHttpRequest идет в пень. Потому что в противном случае на клиент что-то для замены этого объекта придется доставить или же реализовывать через ж... (ифреймами к примеру).
Поэтому сравнивать прикладное программирование с веб программированием в такой формулировке просто нельзя. Другая специфика, ты совершенно не волен над клиентской стороной.
и
Так я могу писать асинхронку или нет? И чем передача через iframe не асинхронка?
Ты совершенно не волен над ОС.
Несогласен. Если ресурс с низкой посещаемостью и форма проверяется редко, действительно, ее лучше проверять только на сервере. А если сервак загружен по полной, то так может помочь ему проверив форму у клиента, и в случае удачи отправить какой то ключ, который значит, что форма проверена и можно смело работать с данными?
нет. Если у клиента javascript работает, то он проверяет форму и отдает на сервер какой-то флаг (который значит что форма проверена и с данными можно работать без проверки), если флаг от яваскрипта не пришел то сервер САМ начинает проверять форму
Допустим, создал я прикладную программу и ручным методом отправил "ключ" серверу, мол "все ок, сервер, ты не переживай, данные отправлены", а сам - пихнул ему вредный код, ту же мускульную инъекцию. Что с этой стороны скажешь? Или я не совсем понял твой подход?
идею понял ты правильно, и аргумент веский. Пока не знаю что ответить, первое что пришло в голову проверить заголловок запроса на предмет откуда он пришел, но его также можно подделать. Точно отвечу в понедельник или признаю себя виновным.
Ты там это... сильно не переживай, хорошо?
или признаю себя виновным ***здесь должен быть смайлик, который пускает себе пулю в висок*** :)
Точно отвечу в понедельник или признаю себя виновным.
А чего тянуть? Я с самого начала сказал, что ты совершенно не прав. Ты не поверил (видимо сказывается отсутствие опыта и плохая теоретическая подготовка), но к понедельнику ни чего изобреться тебе не получиться. JS это клиентский язык, а данным с клиента верить НЕЛЬЗЯ. Это аксиома, это азы безопастности сайта.
Как раз на сайте с малой перещаемостью твою схему что бы не париться практиковать можно. Сломают и хрен с ним, все равно пользователей мало. А на ресурсы с большим количество посещений это не пойдет, всегда найдется тот, кто захочет ресурс хакнуть.