Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Почитать больше о CoffeeScript можно тут — cidocs.ru/coffeescript/
if data isnt off
Воу-воу-воу, меньше наворотов! Если они есть — это не значит, что надо применить все сразу :) «if data»
if @errors_list is undefined @errors_list = {} if @errors_list[field] is undefined @errors_list[field] = []
Отличные оператор есть
||=@errors_list ||= {}
@errors_list[field] ||= []
Кстати слово list тут лишнее, да еще и неправда, у вас хэш, а не список :)
В редакторе нет подсветки Coffee, использовал питоновскую.
На Ruby подсветку смените, лучше подходит.
Воу-воу-воу, меньше наворотов!
Временами хочется поэзии, чисто для разнообразия :)
Отличные оператор есть ||=
Упс, косяк. Спасибо!
По теме, сугубо из желания сделать мир лучше, субъективное мнение. Статью закончил читать с некоторым разочарованием. Сам по себе пример вполне жизненный, валидация — добро, и не только для форм :) Но исполнение не очень радует.
К статье:
Зачем двойной листинг с комментариями? Под кат бы его, он только сбивает с толку свои появлением второй раз, когда уже собрался читать дальше :) Да и когда тебе показывают комментарии в духе "# вернет true, если число больше заданного", невольно начинаешь чувствовать себе идиотом.
Тема классов не раскрыта совсем. Даже конструктора нет, не говоря про полиморфизм и т.д., в вашем примере никакой разницы не было бы, даже если все переписать на глобальные функции переменные. Вы даже после создания инстанса сразу уничтожаете класс :)
По коду:
Чем вам так нравятся инверсные условия? Я лично в таким нагромождениях уже не могу с ходу их разобрать:
Что, простите? О_о Это не конкурс головоломок, это же код. К слову, комментарий тут под стать коду и тоже ломает мозг(не просили, но не получили...?!). Мне лично кажется, что в этом условии даже есть ошибка. (Правило внесения отрицания под скобки: !(a && b) раскрывается как !a || !b)
Зачем ошибки отделены от класса в отдельный внешний объект? Это же часть логики класса, хранили бы их в статическом поле класса.
Почтой валидатор не пропустит мой ящик :) Объект класса назван с маленькой буквы, да и правильнее назвать «Validator» — вроде бы и мелочь, но неопрятно. Еще всякие мелочи бросаются в глаза. Нормальный прототип, но в продакшн в такой виде не пустил бы :)
Если вы хотите опубликовать цикл примеров — заведите репу на гитхабе, выложите их там рядом со всеми необходимым зависимостями и страничкой-примером, вам спасибо большое только скажут :)
К статье:
Зачем двойной листинг с комментариями? Под кат бы его, он только сбивает с толку свои появлением второй раз, когда уже собрался читать дальше :) Да и когда тебе показывают комментарии в духе "# вернет true, если число больше заданного", невольно начинаешь чувствовать себе идиотом.
Тема классов не раскрыта совсем. Даже конструктора нет, не говоря про полиморфизм и т.д., в вашем примере никакой разницы не было бы, даже если все переписать на глобальные функции переменные. Вы даже после создания инстанса сразу уничтожаете класс :)
validation = new validation
По коду:
Чем вам так нравятся инверсные условия? Я лично в таким нагромождениях уже не могу с ходу их разобрать:
unless result in [true,false]
...
# если не просили пустую строку, но ничего не получили
else unless 'required' not in rules and str.length is 0
if result is no
Что, простите? О_о Это не конкурс головоломок, это же код. К слову, комментарий тут под стать коду и тоже ломает мозг(не просили, но не получили...?!). Мне лично кажется, что в этом условии даже есть ошибка. (Правило внесения отрицания под скобки: !(a && b) раскрывается как !a || !b)
Зачем ошибки отделены от класса в отдельный внешний объект? Это же часть логики класса, хранили бы их в статическом поле класса.
Почтой валидатор не пропустит мой ящик :) Объект класса назван с маленькой буквы, да и правильнее назвать «Validator» — вроде бы и мелочь, но неопрятно. Еще всякие мелочи бросаются в глаза. Нормальный прототип, но в продакшн в такой виде не пустил бы :)
Если вы хотите опубликовать цикл примеров — заведите репу на гитхабе, выложите их там рядом со всеми необходимым зависимостями и страничкой-примером, вам спасибо большое только скажут :)
Позвольте отчасти с вами не согласиться, коллега.
Перфекционизм с одной стороны, и сделать «чтобы работало» с другой стороны — оба экстремума плохи, так как чреваты повышенными потерями времени и сил. Есть масса срединных вариантов, один из них я как раз и показал. Предложенное решение хорошо тем, что оно написано менее, чем за полчаса, работает и, что немаловажно, правится и расширяется, в том числе методом перегрузки.
Конструктор — это возможность, а не необходимость. В данном случае применения ему я не вижу. Объект, кстати, не разрушается, но ключевые свойства инициируются при каждом вызове. Так надо.
Запутанный кусок, формулирующий логику, действительно формулирует запутанную логику. Эта логика именно такова — пустую строку можно ожидать, а можно и не ожидать, при этом она может быть, а может и не быть, и бизнес-логика приложения может подразумевать именно четыре варианта. Это случай из практики, мне будет сложно его объяснить тому, кто с этим не сталкивался.
Некоторым читателям удобнее так, некоторым эдак. Проскроллить действительно несложно. А как сделать кат? Вы имеете в виду, чтобы сворачивалось?
Перфекционизм с одной стороны, и сделать «чтобы работало» с другой стороны — оба экстремума плохи, так как чреваты повышенными потерями времени и сил. Есть масса срединных вариантов, один из них я как раз и показал. Предложенное решение хорошо тем, что оно написано менее, чем за полчаса, работает и, что немаловажно, правится и расширяется, в том числе методом перегрузки.
Конструктор — это возможность, а не необходимость. В данном случае применения ему я не вижу. Объект, кстати, не разрушается, но ключевые свойства инициируются при каждом вызове. Так надо.
Запутанный кусок, формулирующий логику, действительно формулирует запутанную логику. Эта логика именно такова — пустую строку можно ожидать, а можно и не ожидать, при этом она может быть, а может и не быть, и бизнес-логика приложения может подразумевать именно четыре варианта. Это случай из практики, мне будет сложно его объяснить тому, кто с этим не сталкивался.
Зачем двойной листинг с комментариями?
Некоторым читателям удобнее так, некоторым эдак. Проскроллить действительно несложно. А как сделать кат? Вы имеете в виду, чтобы сворачивалось?
Я просто к тому, что это решение на скорую руку — вполне подойдет для решения задачи здесь и сейчас, но вы все-таки статью пишете, которую другие люди будут читать. Мне кажется они заслуживают хорошего продуманого кода. По этой же причине я и говорю про нехватку ООП и OOAD. Как видите, не набрали и десятка плюсов — что как ни это является подтверждением моих слов.
Про запутанный кусок — мне кажется тут не логика запутанная, а вы ее путаете. Если я правильно понимаю, то вы имели ввиду следующее:
Про запутанный кусок — мне кажется тут не логика запутанная, а вы ее путаете. Если я правильно понимаю, то вы имели ввиду следующее:
if result in [true, false]
if ('required' in rules || str.length > 0) && result == false
... # ловим ошибку
else
.... # перепишем результат
они заслуживают хорошего продуманого кода
Именно это я и хотел показать. Фактически, есть единственный способ для того, чтобы обезопасить себя от перфекционизма — иметь часы перед глазами.
Какой смысл в суперразработчиках, если они тратят время и деньги своего работодателя на то, чтобы сделать суперкрасивый код, вместо того, чтобы добиться вполне утилитарных задач: сделать его быстро, и сделать его сопровождаемым?
('required' in rules || str.length > 0) && result == false
Это не Coffee.
Как видите, не набрали и десятка плюсов — что как ни это является подтверждением моих слов.
Не уверен :)
Вообще, тут очень многие хорошие статьи не набирают должного количества плюсов. Вопрос в аудитории — лет пять назад она была принципиально другой. Сейчас она изрядно помолодела, а у нынешнего поколения книжки не в моде. Чтению они предпочитают видео, яркие простые картинки и алкоголь.
Это не Coffee.
coffee> if ('required' in rules || str.length > 0) && result == false then true else false
false
O RLY? Но даже если бы был косяк в синтаксисе — вы игнорите главный тезис, что зачем-то навернули сложности.
Сейчас она изрядно помолодела, а у нынешнего поколения книжки не в моде. Чтению они предпочитают видео, яркие простые картинки и алкоголь
Спасибо, да, запишу на свой счет, что я книжки не читаю и предпочитаю яркие простые картинки и алкоголь, раз вы так лихо про всех все знаете :)
Материал невысокого качества. Это не повод оправдываться «утилитарностью и воздержанием от перфексионизма» — не бойтесь, он вам не грозит. Что бы не тратить время — пишите хороший код сразу, что вам мешает :) Не можете — тренируйтесь! Как раз на тему книг — вам бы «Совершенный код» и «Рефакторинг. Улучшение существующего кода» прочитать. Они не привязаны к языкам и как крутятся вокруг тем хорошего/плохого/достаточно хорошего кода.
По поводу дизайна — не самым лучшим решением преставляется описание правил в виде строки.
Если кто-то совершит опечатку, то об этом узнаете только при вызове метода. Плюс работа зависит от порядка.
Если написать правило «required|trim», то оно провалидирует строчку из пустых пробелов — сначала проверит, что длинна строки больше 0, потом отрежет все пробелы и сохранит новое значение. Очевидно, это косяк дизайна. По хорошему сначала должны применяться все морферы (операции, изменяющие строку), только потом делаться валидация, причем очевидно возникают приоритеты в ошибках.
Для правила «valid_email|required» по хорошему надо в любом случае сначала проверять на required, убедившись, что данные вообще есть, и только потом применять к ним любые другие валидаторы — а у вас первым сработает valid_email и юзер получит ошибку про неправильный email(а не про его обязательность).
Эти проблемы не вылечить одной строчкой, и что бы решение было общим — надо усложнить структуру объекта и логику работы.
Скрывать текст можно тегом <spoiler title="...">...</spoiler>:
Если кто-то совершит опечатку, то об этом узнаете только при вызове метода. Плюс работа зависит от порядка.
Если написать правило «required|trim», то оно провалидирует строчку из пустых пробелов — сначала проверит, что длинна строки больше 0, потом отрежет все пробелы и сохранит новое значение. Очевидно, это косяк дизайна. По хорошему сначала должны применяться все морферы (операции, изменяющие строку), только потом делаться валидация, причем очевидно возникают приоритеты в ошибках.
Для правила «valid_email|required» по хорошему надо в любом случае сначала проверять на required, убедившись, что данные вообще есть, и только потом применять к ним любые другие валидаторы — а у вас первым сработает valid_email и юзер получит ошибку про неправильный email(а не про его обязательность).
Эти проблемы не вылечить одной строчкой, и что бы решение было общим — надо усложнить структуру объекта и логику работы.
Скрывать текст можно тегом <spoiler title="...">...</spoiler>:
Код с комментариями
Открывается и все показывает
не самым лучшим решением преставляется описание правил в виде строки...
Вот и вы тоже невнимательны. Решена конкретнейшая утилитарная задача, по условиям ТЗ: «портировать правила CodeIgniter с сервера на клиент». Там есть и соглашения о порядке следования правил. Зачем мне лезть со своим мнением в API, если целью является простое его использование?
А то, о чем вы подумали, многократно реализовано, например в jQuery Forms. И многие подумали также. Поэтому и минусы — просто непонимание вследствие невнимательности. Слишком много тезисов… :)
Скрывать текст можно тегом
Спасибо!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CoffeeScript в примерах. Валидация