Комментарии 16
А как же заявленный JS на странице формы, который якобы может манипулировать со списком значений выпадающих списков (я уж не говорю о валидации, которая может висеть на onSubmit/onChange/onKeyPress)?
Так это ничем не противоречит. Мы же в любом случае перед реализацией видим исходный код формы. Что нам мешает выполнять $(«some selector»).trigger(«change»); на полях формы в нашем скрипте?
И почему же тогда ту же логику не повторить нативно? Да, конечно, она может быть так сложна, что потребуется целый человеко-день на повторение, но если вдруг сменится html-выдача, а вместе с ней и название селектора, что тогда?
Никто и не говорит, что повторять нативно — это плохо. Просто обычно хочется универсального решения, а использование данной техники оправдано во многом ввиду того, что скрипты для работы с формами являются едиными для работы под разные мобильные платформы (мы используем, например, одинаковые и для iOS и для Android), т.е. разрабатываем и поддерживаем синхронно, что, согласитесь немаловажно.
А что если у юзера карта с 3d secure и он должен вводить смс код на странице своего банка?
НЛО прилетело и опубликовало эту надпись здесь
fhcvhh
Цвет хедеров бы сделать «по мягче», выедает глаза и не позволяет ничего прочитать после него.
Небольшой оффтоп:
и
…вместе как-то не уживаются, или забыли, что такое склонения, и учились в школа, ездили в автобус и ходили на работа? :-). Нужно давать в таких случаях в глаз бренд-менеджеру учебником русского языка.
но ее внешний вид не совпадает с представлениями о прекрасном нашего отдела дизайна и выглядит внутри неорганично.
и
Со счета Билайн
…вместе как-то не уживаются, или забыли, что такое склонения, и учились в школа, ездили в автобус и ходили на работа? :-). Нужно давать в таких случаях в глаз бренд-менеджеру учебником русского языка.
Я тоже использую такой подход в своих приложениях. Есть интересный момент, сталкивались ли вы когда-нибудь с ограничением stringByEvaluatingJavaScriptFromString: на 10mb используемой памяти и 10sec на исполнение?
Если взять пример с карточными платежами, получится, что пользователь вводит платёжные реквизиты не на «родной» странице банка, а в приложении. При таком подходе не возникнет проблем с процессингом, банком-эквайером или МПС? На кого переложат риски за скомпрометированные транзакции в таком случае?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
С любовью к дизайнерам: внедряем веб-формы в мобильное приложение