Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

(js) унифицированный скрипт проверки данных формы

7.8K
25 ноября 2007 года
Hrew
185 / / 23.04.2007
Здравствуйте. Передо мной встала задача написания единого яваскрипта, который мог бы проверить правильность данных любой формы, какую только придумает веб-мастер. Загвоздка возникла с проверкой заполненности/незаполненности полей, обязательных для ввода. Была мысль ввести дополнительный атрибут для элементов формы (например, [FONT="Courier New"]<input type="text" ... not_null="yes">[/FONT]) и при submit'е делать обход всех элементов и проверять наличие этого параметра и заполненность поля, но это понимает только IE (а у нас местами используются еще и опера с файрфоксом).
Каким путем можно решить эту задачу?
Страницы:
12
25 ноября 2007 года
alekciy
3.0K / / 13.12.2005
Проверка введеных данных на клиенте не более чем клиентское дополнение. Контроль на сервере все равно обязателен.

Цитата:

и при submit'е делать обход всех элементов и проверять наличие этого параметра и заполненность поля, но это понимает только IE


Если ты имеешь в виду нативная поддежка, то может быть, а если такой обработчик полей формы ты пишешь сам, то нифига. Будет работа везде если ты позаботишься о кроссплатформенности.

Почитай вот это: HTML_MetaForm: извлечение информации о структуре HTML-формы и ее обработка и вот это HTML_FormPersister: новый взгляд на построение форм.

353
25 ноября 2007 года
Nixus
840 / / 04.01.2007
Цитата: Hrew
Здравствуйте. Передо мной встала задача написания единого яваскрипта, который мог бы проверить правильность данных любой формы, какую только придумает веб-мастер. Загвоздка возникла с проверкой заполненности/незаполненности полей, обязательных для ввода. Была мысль ввести дополнительный атрибут для элементов формы (например, [FONT="Courier New"]<input type="text" ... not_null="yes">[/FONT]) и при submit'е делать обход всех элементов и проверять наличие этого параметра и заполненность поля, но это понимает только IE (а у нас местами используются еще и опера с файрфоксом).
Каким путем можно решить эту задачу?



Лучше хранить список имен элементов формы, которые нужно проверять.
[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]

7.8K
26 ноября 2007 года
Hrew
185 / / 23.04.2007
Цитата: Nixus
Лучше хранить список имен элементов формы, которые нужно проверять.


Да, спасибо. Не берусь судить о том, лучше это (чем направление, данное alekciy) или нет, но то что быстрее - это однозначно (быстрее в плане освоения решения - не нужно беспокоиться о внедрении php-решений в мой не-php проект).

12
26 ноября 2007 года
alekciy
3.0K / / 13.12.2005
Не проверят данные на сервере полученные с клиента крайне не осмотрительно со стороны веб кодера.
7.8K
26 ноября 2007 года
Hrew
185 / / 23.04.2007
Цитата: alekciy
Не проверят данные на сервере полученные с клиента крайне не осмотрительно со стороны веб кодера.



alekciy, Вы упоминаете об этом уже второй раз. Для очистки совести скажу, что на стороне сервера я проверяю и кромсаю данные, как мне требуется, ибо это моя вотчина. Об этой стороне я собственно и не спрашиваю. А вот клиентская сторона - хотя и не моя задача, но тоже почему-то достается мне. Пока решение, предложенное Nixus и уже мной реализованное, всех устроило и все довольны.

256
26 ноября 2007 года
foxweb
1.0K / / 27.07.2005
В таком случае лучше реализовать на AJAX - одним выстрелом двух зайцев. Кстати, делается возможно даже проще, чем тоже самое по отдельности. Sajax прикрутить - 5 минут.
2.1K
26 ноября 2007 года
vectoroc
234 / / 25.07.2006
http://blog.jc21.com/2007-02-05/yui-unobstrusive-javascript-validation/ - легко переписывается на нужный тебе framework или работу без него.
http://www.jsvalidate.com/ - покрасивше, но потянет за собой prototype+scriptaculo
256
27 ноября 2007 года
foxweb
1.0K / / 27.07.2005
Цитата: vectoroc
http://www.jsvalidate.com/ - покрасивше, но потянет за собой prototype+scriptaculo



Ну говорил же, без AJAX тут не обойтись - проверка сразу сервером и не отходя от кассы.

353
27 ноября 2007 года
Nixus
840 / / 04.01.2007
По-моему, вы наворачиваете лишнее. Нет смысла сюда прикручивать ajax, т.к. проверка формы у клиента делается как раз для того чтобы определить простейшие ошибки без отправки запроса. Ваш вариант:
1) усложнит серверный скрипт, что в конце концов может привести к появлению проблем с безопасностью
2) требует вносить изменние в уже рабочие скрипты, что не всегда желательно и возможно
3) увеличивает нагрузку на сервер

По-моему, оно того не стоит.
2.1K
27 ноября 2007 года
vectoroc
234 / / 25.07.2006
Цитата: foxweb
Ну говорил же, без AJAX тут не обойтись - проверка сразу сервером и не отходя от кассы.



Автор сказал что обязательно нужен AJAX?
Я предложил варианты без AJAX-а, как первичная проверка (заполнено/число/дата...) самое-то

7.8K
28 ноября 2007 года
Hrew
185 / / 23.04.2007
Цитата: vectoroc
Автор сказал что обязательно нужен AJAX?
Я предложил варианты без AJAX-а, как первичная проверка (заполнено/число/дата...) самое-то


Нет, автор (то есть я) и не заикался об ajax, т.к. был твердо уверен в том, что ему нужен именно javascript.

Цитата: foxweb
Ну говорил же, без AJAX тут не обойтись


А я как раз собираюсь обойтись без него. Я не сторонник применения технологий ради применения технологий, а именно так у меня с ajax'ом и получится. Тем более что главная моя цель использования js - ограничение числа походов на сервер.

12
28 ноября 2007 года
alekciy
3.0K / / 13.12.2005
Цитата: Hrew
Нет, автор (то есть я) и не заикался об ajax, т.к. был твердо уверен в том, что ему нужен именно javascript.


AJAX это и есть JavaScript.

353
28 ноября 2007 года
Nixus
840 / / 04.01.2007
Цитата: alekciy
AJAX это и есть JavaScript.


AJAX есть методология программирования с использованием асинхронных клиенских запрсов и можно тоже самое на VB делать. Да и без серверных скриптов далеко на AJAX не уедешь. Поэтому, позвольте не согласиться, что AJAX это и есть JavaScript.
Эта фраза эквивалентна: "ООП это и есть C++".

12
28 ноября 2007 года
alekciy
3.0K / / 13.12.2005
Цитата: Nixus
AJAX есть методология программирования с использованием асинхронных клиенских запрсов и можно тоже самое на VB делать.


Это безусловно методология. Но за ней конкретный программный код, конкретный обекты. Тот же VB к браузеру ты просто так не прикрутишь. А учитывая, что про аякс стали говорить после статьи Гаррета, то в ней он как раз и указывает, что один из основных компонентов такой системы это JS. Поэтому сейчас уж так получается, говорим аякс, понимаем XMLHttpRequest объект.

353
28 ноября 2007 года
Nixus
840 / / 04.01.2007
Цитата: alekciy
Это безусловно методология. Но за ней конкретный программный код, конкретный обекты. Тот же VB к браузеру ты просто так не прикрутишь. А учитывая, что про аякс стали говорить после статьи Гаррета, то в ней он как раз и указывает, что один из основных компонентов такой системы это JS. Поэтому сейчас уж так получается, говорим аякс, понимаем XMLHttpRequest объект.



Цитата:
Q. Is Ajax just another name for 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, но этот элемент далеко не единственный. И сопоставляь их - суть кривда.

12
28 ноября 2007 года
alekciy
3.0K / / 13.12.2005
До того, как появился XMLHttpRequest в браузерах об аяксе ни кто и говорил. Безусловно были реализации на практике этой технологии, но решалось это привинчиваем на браузер сторонних модулей.

Так что пока не было XMLHttpRequest в JS небыло и аякса. Сама технологи по хорошему называется не аяксом, это технология "асинхронного обмена данными между клиентом и сервером в фоном режими". Вот это технология, вот это может быть реализованно на разных языках. Что собсвенно и делалось наиболее продвинутыми разрабами задолго до аякса.

Но вот в браузерах появилась поддежка XMLHttpRequest (даже странно, что такую хорошую идею реализовал MS первым из всех). И используя уже известную технологию (особо это поддеркиваю) стали писать клиентские приложения. И обозвали все это дело аяксом.

Поэтому если уж мы говорим об асинхронном обмене данными с сервером, то это любой язык, а уж коль упомянули аякс, то предполагаем использование JS на клиенте для реализации этого подхода.
353
28 ноября 2007 года
Nixus
840 / / 04.01.2007
Это уже дело принципа что имеено называть AJAX. Понятия имеют тенднцию по мере развития технологий изменяться.
Если исходить из твоего принципа, что AJAX это XMLHttpRequest и JavaScript, то я скажу так: AJAX без JavaScript не возможен, а JavaScript без AJAX'а вполне. Даже в твоем базисе это утверждение весьма спорно, а если принять базис, что AJAX это методолигия асинхронного программирования, тем боле. И твоя поправка Hrew весьма не к месту была.
12
28 ноября 2007 года
alekciy
3.0K / / 13.12.2005
Кстати асинхронки от MS зовутся Atlas-ом. Т.е. говорим Atlas имеем в виде ActiveX объект.

З.Ы.
AJAX (Asynchronous JavaScript and XML)

А насчет аякса ты видимо мой пост не понял. Я не говорю, что AJAX == JavaScript (неужели меня можно заподзрить в таком ламеризме?!??!). Ты перечитай тот пост в контексте предыдуших ;)
353
28 ноября 2007 года
Nixus
840 / / 04.01.2007
Atlas - тот же AJAX на клиентской стороне.
Я и читал пост в контксте предыдущих. Hrew сказал немного не точно, но ему, т.к. он не в теме, простительно, а вот завсегдатаю форума да еще и в теме...
Вообщем флудить можно еще долго. Предлагаю прекратить... )
12
30 ноября 2007 года
alekciy
3.0K / / 13.12.2005
Цитата: Nixus
а вот завсегдатаю форума да еще и в теме...
Вообщем флудить можно еще долго. Предлагаю прекратить... )


Вот именно. Потому как в теме имею право на свою точку зрения. Технически обоснованную кстати, тем более в контексте данной темы.

353
30 ноября 2007 года
Nixus
840 / / 04.01.2007
Цитата: alekciy
Вот именно. Потому как в теме имею право на свою точку зрения. Технически обоснованную кстати, тем более в контексте данной темы.


Каждый имеет право, на свою точку зрения, это раз.
Если человек в теме, то это не гарантирует что он не ляпнет глупость, это два.
"AJAX это и есть JavaScript."
Заменим в диалоге AJAX на stdlib, а JavaScript на C++.

Цитата:
[QUOTE=Hrew]Нет, автор (то есть я) и не заикался об stdlib, т.к. был твердо уверен в том, что ему нужен именно C++.


stdlib это и есть C++.[/QUOTE]
Заметна абсурдность утверждения?

ПП. Понизившего репутацию тут тоже приглашаю к дискусии, если есть что сказать.

12
30 ноября 2007 года
alekciy
3.0K / / 13.12.2005
Цитата: Nixus

Заметна абсурдность утверждения?


Сравнение не совсем корректно. Ситуация с компилируемыми языками в данном случае немного другая. Есть четкая спецификация на язык, там все создатели и обозначиют. Используемую терминологию в том числе. Парадигма-с....

А тут? Гаррет взял, да и придумал новую аббревиатуру к не новому уже понятию. А MS взяло и фактически к тому же самому придумало своё в реализации через ActiveX. Кто во что горазд... вот W3C те молодцы, хотя они всегда работали на уровне абстракций, просто взяли и описали API объекта.

Так что я не утверждаю, что жаба это аякс, а аякс это жаба и это просто синонимы. Я отлично знаю разницу между ними. Уж спецуху на XMLHttpRequest читал еще только когда она вышла в черновом варианте.

12
30 ноября 2007 года
alekciy
3.0K / / 13.12.2005
Цитата: Nixus

ПП. Понизившего репутацию тут тоже приглашаю к дискусии, если есть что сказать.


Ого! Интрига! :D
Я то думал это ты :) . Теперь и мне интересно.

353
30 ноября 2007 года
Nixus
840 / / 04.01.2007
Цитата: alekciy
Сравнение не совсем корректно. Ситуация с компилируемыми языками в данном случае немного другая. Есть четкая спецификация на язык, там все создатели и обозначиют. Используемую терминологию в том числе. Парадигма-с....


Я о том, что ты можешь в C++ как использовать стандартную библиотеку, так и не использовать ее (использовать любую другую). Сам C++ от этого не убудет.
Так же как можешь использовать XMLHttpRequest в JavaScript, а можешь и не использовать.

33K
30 ноября 2007 года
Murzik
10 / / 30.11.2007
По моему тема ушла куда-то в сторону от темы :). И собственно возвращаясь к теме, о том надо ли проверять форму на сервере, безусловно надо, НО только в том случае если форму по каким то причинам не проверил JavaScript. (отключен, непрогрузился и т.п.)
12
01 декабря 2007 года
alekciy
3.0K / / 13.12.2005
Цитата: Nixus

Так же как можешь использовать XMLHttpRequest в JavaScript, а можешь и не использовать.


Можешь. Только асинхронный обмен с сервером через стандартный набор HTML+CSS+JavaScript ты на нормальном браузере уже не огранизуешь.
Конечно, можно привлеч к этому делу флеш (вот флекс супер) с тем же результатом. Но. Флеш на браузере отключен чаще, чем JS в силу того, что вебразработы попросту своей работой дескридитировали саму технологию.

12
01 декабря 2007 года
alekciy
3.0K / / 13.12.2005
Цитата: Murzik

И собственно возвращаясь к теме, о том надо ли проверять форму на сервере, безусловно надо, НО только в том случае если форму по каким то причинам не проверил JavaScript. (отключен, непрогрузился и т.п.)


Совершенно неправильный и даже вредный совет. Данные с клиента нужно на сервере проверять ВСЕГДА.

353
01 декабря 2007 года
Nixus
840 / / 04.01.2007
Цитата: alekciy
Можешь. Только асинхронный обмен с сервером через стандартный набор HTML+CSS+JavaScript ты на нормальном браузере уже не огранизуешь.


Совсем не понял о чем ты.

12
01 декабря 2007 года
alekciy
3.0K / / 13.12.2005
Цитата: Nixus
Совсем не понял о чем ты.


Цитата:

Так же как можешь использовать XMLHttpRequest в JavaScript, а можешь и не использовать.


Если ты организуешь асинхронку, у тебя нет выбора использовать/не_использовать. Это в С++ хочешь юзать стандартную либу, юзаешь её. Не нравиться, подключаешь к проекту любую другую нужную и на выходе (заказчику) отдаешь готовое приложение реализующее требуемый функционал.

С веб программингом так нельзя. Ты не можешь писать асинхронку и сказать, да пусть этот XMLHttpRequest идет в пень. Потому что в противном случае на клиент что-то для замены этого объекта придется доставить или же реализовывать через ж... (ифреймами к примеру).

Поэтому сравнивать прикладное программирование с веб программированием в такой формулировке просто нельзя. Другая специфика, ты совершенно не волен над клиентской стороной.

353
01 декабря 2007 года
Nixus
840 / / 04.01.2007
Цитата: alekciy
Ты не можешь писать асинхронку и сказать, да пусть этот XMLHttpRequest идет в пень.


и

Цитата: alekciy
Потому что в противном случае на клиент что-то для замены этого объекта придется доставить или же реализовывать через ж... (ифреймами к примеру).


Так я могу писать асинхронку или нет? И чем передача через iframe не асинхронка?

Цитата: alekciy
Поэтому сравнивать прикладное программирование с веб программированием в такой формулировке просто нельзя. Другая специфика, ты совершенно не волен над клиентской стороной.


Ты совершенно не волен над ОС.

33K
01 декабря 2007 года
Murzik
10 / / 30.11.2007
Цитата: alekciy
Совершенно неправильный и даже вредный совет. Данные с клиента нужно на сервере проверять ВСЕГДА.



Несогласен. Если ресурс с низкой посещаемостью и форма проверяется редко, действительно, ее лучше проверять только на сервере. А если сервак загружен по полной, то так может помочь ему проверив форму у клиента, и в случае удачи отправить какой то ключ, который значит, что форма проверена и можно смело работать с данными?

15
01 декабря 2007 года
shaelf
2.7K / / 04.05.2005
2Murzik Т.е. ты предлагаешь проверять ТОЛЬКО на js?
33K
01 декабря 2007 года
Murzik
10 / / 30.11.2007
shaelf
нет. Если у клиента javascript работает, то он проверяет форму и отдает на сервер какой-то флаг (который значит что форма проверена и с данными можно работать без проверки), если флаг от яваскрипта не пришел то сервер САМ начинает проверять форму
12
01 декабря 2007 года
alekciy
3.0K / / 13.12.2005
Прошу привести конкретный алгорит или еще лучше програмную реализацию изложенной идеи. А так это все вилами по воде, чистые асбракции.
15
01 декабря 2007 года
shaelf
2.7K / / 04.05.2005
2Murzik Хорошо, я скачал страничку на комп, переписал JS и отправил на сервер. Что дальше?
251
01 декабря 2007 года
SkyMаn
1.7K / / 31.07.2007
Цитата: Murzik
А если сервак загружен по полной, то так может помочь ему проверив форму у клиента, и в случае удачи отправить какой то ключ, который значит, что форма проверена и можно смело работать с данными?


Допустим, создал я прикладную программу и ручным методом отправил "ключ" серверу, мол "все ок, сервер, ты не переживай, данные отправлены", а сам - пихнул ему вредный код, ту же мускульную инъекцию. Что с этой стороны скажешь? Или я не совсем понял твой подход?

33K
01 декабря 2007 года
Murzik
10 / / 30.11.2007
Skym@n
идею понял ты правильно, и аргумент веский. Пока не знаю что ответить, первое что пришло в голову проверить заголловок запроса на предмет откуда он пришел, но его также можно подделать. Точно отвечу в понедельник или признаю себя виновным.
251
01 декабря 2007 года
SkyMаn
1.7K / / 31.07.2007
Цитата: Murzik
...или признаю себя виновным.


Ты там это... сильно не переживай, хорошо?

33K
01 декабря 2007 года
Murzik
10 / / 30.11.2007
даже не подумаю, но решение найду все равно...
или признаю себя виновным ***здесь должен быть смайлик, который пускает себе пулю в висок*** :)
12
01 декабря 2007 года
alekciy
3.0K / / 13.12.2005
Цитата: Murzik
Skym@n
Точно отвечу в понедельник или признаю себя виновным.


А чего тянуть? Я с самого начала сказал, что ты совершенно не прав. Ты не поверил (видимо сказывается отсутствие опыта и плохая теоретическая подготовка), но к понедельнику ни чего изобреться тебе не получиться. JS это клиентский язык, а данным с клиента верить НЕЛЬЗЯ. Это аксиома, это азы безопастности сайта.

Как раз на сайте с малой перещаемостью твою схему что бы не париться практиковать можно. Сломают и хрен с ним, все равно пользователей мало. А на ресурсы с большим количество посещений это не пойдет, всегда найдется тот, кто захочет ресурс хакнуть.

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог