Я понимаю в чём смысл валидации на клиенте, честно. И отказался от неё совершенно осознано. В наше время быстрых каналов экономия времени получается на спичках, а деньги сэкономленные от работы над скриптом валидации проще вложить в апгрейд сервера, это будет лучше чем избегать нагрузки подобным способом.
Кроме того, проведённая вами параллель не совсем удачна: сжатие JS/CSS это простая технология. А логика валидации это, как ни крути, код со всеми из него вытекающими: поддержка, апдэйт либ в случае использования сторонних решений, рефакторинг.
Я понимаю, допустим, использование рэгэксп-маски на поле, там скрипт простой и универсальный, пару строчек кода в логике. Написание же полноценной валидации это всегда разработка нового мета-языка обозначений: not_empty, is_email, is_url, is_phone и т. п. И везде оно разное, хотя и стандарты тоже есть. Дублировать довольно таки сложную и трудоёмкую логику я не вижу смысла.
То есть, вы предлагаете написать ещё дополнительный код, который будет связывать воедино логику сервера и клиента, вместо того, чтобы оставить только код на сервере?
Кроме того, генераторы форм практически всегда оборачиваются головняком для верстальщика. Особенно, если внешний вид формы нужно кастомизировать. А ещё можно вспомнить ситуации, когда форма динамически генерируется на клиенте. Предлагаете в этом случае обращаться к серверу, чтобы он сгенерировал нам форму?
Я просто не вижу смысла оставлять клиент-валидацию. Зачем она? Ну ладно, проверка занятости логина, как выше писали. Но зачем делать дважды одну и ту же проверку обычных полей ума не приложу.
Бейте меня ногами, но я полагаю, что валидация должна быть только одна — на стороне сервера. Причины простые: на стороне сервера она должна быть обязательно (понятно почему), а значит придётся повторять тот же код. Причём, наверняка, на другом языке.
Я сейчас практически всегда использую AJAX-формы. Проверка на сервере, ответ на клиенте. Массу клиент-кода экономит.
Aux известный товарищ, который знает много страшных слов и любит примерять амплуа покрывателя икс-уями. Это не значит, что в пику ему стоит называть вещи не своими именами.
«Зло», как вы выразились, вовсе не в том, чтобы сокращать запись, а в том, чтобы привносить в JS понятия, которых в нём отродясь не было — классы! — и которые там совершенно не нужны. Потому что пользователи библиотек (Мутулз, кстати, моя любимая JS-либа) потом пытаются переносить туда же и логику чуждую языку. Приватные свойства, например. ЗАЧЕМ? Почему я двенадцать лет пишу на JS и мне ни разу не понадобились приватные свойства? Что я делаю неправильно?
Я к тому, что не нужно тащить в язык средства из чуждой ему парадигмы только для того, чтобы мимикрировать под привычную среду.
Выше написали абсолютную правду: использование подсказок по названиям и аргументам сводит вашу логику на нет.
Я, как человек программировавший на многих языках, могу сказать, что объём аналитической работы при разработке на ПХП равен у меня аналогичному объёму для Явы. Ну точнее, для Явы всё же больше, но если убрать оборачивание каждого пука в объект, то где-то столько же.
Геттеры и сеттеры это то, чего ещё пока полноценно не хватает в JS, да. Ещё бы возможность следить за состоянием поля. Как здесь: https://developer.mozilla.org/en/Javascript/Reference/Global_Objects/Object/watch
Я сторонник философии Перла: должно быть более одного способа сделать это. Пусть будет и личка и личные комменты. Тем более, что функционал один и тот же, практически.
Нет, что Вы, это прекрасно! Но иногда хочется пообщаться с автором не прибегая к серьёзной переписке. Тем более, что в топике уже изначально заложена тема для беседы.
Скоро, скоро, благодаря серверному JS у серверных приложений тупо ничего не останется кроме последнего выбора — сдаться. Ну просто так сложилось, что ничто не в состоянии составить конкуренция JS. Питон и Руби могут попытаться, но вряд ли )
Да, на ваш первый вопрос напрямую я не ответил, но как мне казалось написал достаточно. Отвечу сейчас: я с Вами не совсем согласен.
Лично я уже не представляю себе программирования на JS без жонглирования контекстами. Что если контекст это просто абстрактный интерфейс хранящий функцию для другого контекста? А значит и называть и конструировать его следует как хранилище, а не как управляющий объект. А также использовать и описывать в документации.
Поправьте, если я ошибаюсь, но вы рассматриваете контекст исключительно как програмную сущность, а его методы, соответственно, как функционал сущности. Но в JS способов употребления контекстов на порядок шире: я выше перечислил некоторые.
Как это связано с темой поста? Очень просто: представьте, что функция-обработчик разрослась и было принято решение сделать её методом контекста. Такое случается сплошь и рядом. Правильное привязывание контекста гарантирует безболезненный рефакторинг. И это только один пример.
Очевидно, что лучшим решением было бы использовать оба способа — как замыкание, так и привязку контекста — разумно взвешивая необходимость их употребления.
Именно нормально, а не допустимо. И тут я буду спорить до последнего ) Вы программировали на других функциональных языках? Лисп, например?
В этой парадигме функция-метод это базовый кирпичик. А объект его обслуживает. В приведённом мной примере MegaContext.MilliContext это хранилище для метода. А в общем случае, в зависимости от реализации, этот контекст может быть и управляющим объектом, и хранилищем, и интерфейсом, и прототипом.
Если совсем коротко сформулировать, то в JS методы определяют объект, а не объект методы.
Ну и отвечаю на последний Ваш вопрос: я вступил в этот спор потому, что очень люблю Javsscript и, соответственно, не люблю когда в него начинают привносить привычные наработанные приёмы из других языков, которые нарушают его собственную логику.
В JS любая функция это метод какого-то контекста. Если контекст не указан явно, то используется глобальный. Но в функциональных языках программирования нету жёсткой привязки к контексту: объявление метода в одном контексте это не привязка, а просто декларация его «места хранения», если можно так выразиться.
Тем самым исполняя метод одного контекста в другом контексте. В JS это так же естественно как в классическом ООП инициализировать объект класса с помощью конструктора родственного класса.
> Расширение системных прототипов, — дорога в прототип ада :)
Не согласен абсолютно. Волков бояться — в лес не ходить. Опасность расширения родного прототипа это малообоснованное суеверие. Надо просто уметь расширять и, ещё раз, всегда следить за развитием используемого инструмента.
Я лет шесть програмлю регулярно расширяя прототипы для JS, как системные, так и Motools'овские. И, представьте, до сих пор ни единого разрыва )
Расширять системные прототипы не вредно, а нормально и естественно. Просто для этого нужен аккуратный подход и постоянный интерес к развитию языка и используемых им стандартов.
Метод bind в ES5 был внесён именно из библиотек Prototype и Mootools. Так часто бывает, что удачные реализации из либ становятся частью стандарта. Мы не можем при разработке решения предвидеть все будущие ходы разработчиков стандарта, которые в будущем станут конфликтовать с нашим решением. Следовательно, правильный подход: забить на предсказания будущего и разрабатывать как тебе удобно, но при этом, повторюсь, живо следить за развитием стандартов и языка. Ошибка Motools в несоблюдении последнего, а никак не в расширении системных прототипов.
Т. е. методы delay и periodical принимают ссылку на контекст исполнения как параметр. За что я и люблю Mootools, так это за правильную работу с контекстами.
А заставлять своих коллег помнить названия объектов и методов Вы, случайно, усложнением не считаете? )
Выполнение методов в произвольном контексте — как в естественном, так и в кастомном — является неотъемлемым приёмом программирования на JS. Факт наличия «родных» методов apply и call у функции уже говорит об этом. JS функциональный язык, жонглирование контекстом исполнения есмь часть его парадигмы.
Кроме того, проведённая вами параллель не совсем удачна: сжатие JS/CSS это простая технология. А логика валидации это, как ни крути, код со всеми из него вытекающими: поддержка, апдэйт либ в случае использования сторонних решений, рефакторинг.
Я понимаю, допустим, использование рэгэксп-маски на поле, там скрипт простой и универсальный, пару строчек кода в логике. Написание же полноценной валидации это всегда разработка нового мета-языка обозначений: not_empty, is_email, is_url, is_phone и т. п. И везде оно разное, хотя и стандарты тоже есть. Дублировать довольно таки сложную и трудоёмкую логику я не вижу смысла.
Кроме того, генераторы форм практически всегда оборачиваются головняком для верстальщика. Особенно, если внешний вид формы нужно кастомизировать. А ещё можно вспомнить ситуации, когда форма динамически генерируется на клиенте. Предлагаете в этом случае обращаться к серверу, чтобы он сгенерировал нам форму?
Я просто не вижу смысла оставлять клиент-валидацию. Зачем она? Ну ладно, проверка занятости логина, как выше писали. Но зачем делать дважды одну и ту же проверку обычных полей ума не приложу.
Я сейчас практически всегда использую AJAX-формы. Проверка на сервере, ответ на клиенте. Массу клиент-кода экономит.
«Зло», как вы выразились, вовсе не в том, чтобы сокращать запись, а в том, чтобы привносить в JS понятия, которых в нём отродясь не было — классы! — и которые там совершенно не нужны. Потому что пользователи библиотек (Мутулз, кстати, моя любимая JS-либа) потом пытаются переносить туда же и логику чуждую языку. Приватные свойства, например. ЗАЧЕМ? Почему я двенадцать лет пишу на JS и мне ни разу не понадобились приватные свойства? Что я делаю неправильно?
Я к тому, что не нужно тащить в язык средства из чуждой ему парадигмы только для того, чтобы мимикрировать под привычную среду.
Я, как человек программировавший на многих языках, могу сказать, что объём аналитической работы при разработке на ПХП равен у меня аналогичному объёму для Явы. Ну точнее, для Явы всё же больше, но если убрать оборачивание каждого пука в объект, то где-то столько же.
Лично я уже не представляю себе программирования на JS без жонглирования контекстами. Что если контекст это просто абстрактный интерфейс хранящий функцию для другого контекста? А значит и называть и конструировать его следует как хранилище, а не как управляющий объект. А также использовать и описывать в документации.
Поправьте, если я ошибаюсь, но вы рассматриваете контекст исключительно как програмную сущность, а его методы, соответственно, как функционал сущности. Но в JS способов употребления контекстов на порядок шире: я выше перечислил некоторые.
Как это связано с темой поста? Очень просто: представьте, что функция-обработчик разрослась и было принято решение сделать её методом контекста. Такое случается сплошь и рядом. Правильное привязывание контекста гарантирует безболезненный рефакторинг. И это только один пример.
Очевидно, что лучшим решением было бы использовать оба способа — как замыкание, так и привязку контекста — разумно взвешивая необходимость их употребления.
В этой парадигме функция-метод это базовый кирпичик. А объект его обслуживает. В приведённом мной примере MegaContext.MilliContext это хранилище для метода. А в общем случае, в зависимости от реализации, этот контекст может быть и управляющим объектом, и хранилищем, и интерфейсом, и прототипом.
Если совсем коротко сформулировать, то в JS методы определяют объект, а не объект методы.
Ну и отвечаю на последний Ваш вопрос: я вступил в этот спор потому, что очень люблю Javsscript и, соответственно, не люблю когда в него начинают привносить привычные наработанные приёмы из других языков, которые нарушают его собственную логику.
Абсолютно нормально написать что-то типа:
MegaContext.MilliContext.itsMethod.apply(GigaContext.MicroContext);
Тем самым исполняя метод одного контекста в другом контексте. В JS это так же естественно как в классическом ООП инициализировать объект класса с помощью конструктора родственного класса.
Не согласен абсолютно. Волков бояться — в лес не ходить. Опасность расширения родного прототипа это малообоснованное суеверие. Надо просто уметь расширять и, ещё раз, всегда следить за развитием используемого инструмента.
Я лет шесть програмлю регулярно расширяя прототипы для JS, как системные, так и Motools'овские. И, представьте, до сих пор ни единого разрыва )
Ничего личного, всё общее )
Метод bind в ES5 был внесён именно из библиотек Prototype и Mootools. Так часто бывает, что удачные реализации из либ становятся частью стандарта. Мы не можем при разработке решения предвидеть все будущие ходы разработчиков стандарта, которые в будущем станут конфликтовать с нашим решением. Следовательно, правильный подход: забить на предсказания будущего и разрабатывать как тебе удобно, но при этом, повторюсь, живо следить за развитием стандартов и языка. Ошибка Motools в несоблюдении последнего, а никак не в расширении системных прототипов.
method(a).delay(200, this);
Т. е. методы delay и periodical принимают ссылку на контекст исполнения как параметр. За что я и люблю Mootools, так это за правильную работу с контекстами.
Выполнение методов в произвольном контексте — как в естественном, так и в кастомном — является неотъемлемым приёмом программирования на JS. Факт наличия «родных» методов apply и call у функции уже говорит об этом. JS функциональный язык, жонглирование контекстом исполнения есмь часть его парадигмы.