Наложение HTML-страницы на HTML-форму

это вопрос о том, как лучше всего (или с наименьшими усилиями) наложить форму на html-страницу. Лучший в этом контексте означает лучший пользовательский интерфейс при соблюдении функциональных требований.

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

Для пользователей без javascript при нажатии на ссылку будет отправлена ​​короткая форма (с сохранением уже заполненных полей в сеансе), а сервер ответит длинной формой. Они отправят длинную форму, а сервер объединит отправленные данные с сохраненными данными и снова обработает короткую форму — с заполненными полями.

Для пользователей с javascript я хочу наложить страницу короткой формы (в стиле лайтбокса) на длинную форму, позволить им заполнить длинную форму, а затем вернуться к короткой форме с меньшим количеством обращений к серверу.

Do I:

  • Наложить на страницу короткой формы iframe, целью которого является длинная форма?
  • Запросить длинную форму через ajax и вставить ее в div?
  • Создать длинную форму полностью на стороне клиента?
  • Какие-то другие волшебства, о которых я не подумал?

Краткое объяснение наилучшего механизма действительно очень поможет мне. Большое спасибо!


javascript overlay html
person jah    schedule 25.04.2010    source источник
comment
Если вы просите пользователей предоставить финансовую информацию, а вы не знакомы с безопасностью, я бы немедленно отказался от проекта. Из ваших вопросов о наилучшем варианте использования JavaScript, если таковой имеется, я думаю, что ваши знания в области разработки безопасности в лучшем случае ограничены. Не обслуживайте, не запрашивайте использование и не предлагайте какие-либо формы сценариев на стороне клиента, особенно AJAX, если вы работаете с финансовой информацией. Я думаю, вам может понадобиться провести исследование безопасности или нанять консультанта CISSP.   -  person    schedule 26.04.2010
comment
Ха-ха! Отличный и полезный комментарий. Ваши способности к дедукции еще хуже, чем ваша способность понимать написанное. Финансовая информация, о которой идет речь, — это просто та, которая будет введена в кредитный калькулятор — доходы, расходы и тому подобное. Ничего слишком чувствительного. Даже если бы это было так, ваш совет о коде на стороне клиента и финансовой информации сильно попахивает FUD. Спасибо за попытку помочь.   -  person jah    schedule 26.04.2010
comment
@Austin - как ajax / сценарии на стороне клиента / AJAX меняют безопасность на веб-странице?   -  person James Westgate    schedule 26.04.2010
comment
@James Westgate прочитал это: mailmarkup.org/Security_Solution.pdf   -  person    schedule 26.04.2010
comment
Прошу прощения, но я не могу согласиться с этой статьей, которую вы написали, если только я неправильно понимаю некоторые из пунктов, которые вы делаете. В настоящее время я вижу 2 недостатка: 1. Вы утверждаете, что javascript на клиенте небезопасен, но, безусловно, javascript (следовательно, AJAX) изолирован. (Я бы согласился, однако, vv flash, activex и т. д.) 2. Та же политика происхождения - безусловно, мы можем доверять сценарию, который мы получаем из домена, и пока запрос ajax остается в этом домене, проблем быть не должно. Опять же, хороший браузер уведомит вас, если вы переходите на другой домен.   -  person James Westgate    schedule 26.04.2010
comment
@Austin все сценарии на стороне клиента должны считаться потенциально вредоносными, даже если они поставляются из надежного источника ... Достаточно верно. Сценарии на стороне клиента должны быть исключены во всех формах. Конечно, безопасность в пользовательских агентах можно улучшить, но сценарии на стороне клиента никуда не денутся. SAFE тоже не подходит.   -  person jah    schedule 26.04.2010
comment
@jah Я согласен, но только потому, что люди обычно не хотят безопасности. Если бы им нужна была безопасность, они бы в первую очередь работали над тем, чтобы сделать свой код безопасным, чего не хотят многие разработчики. Они хотят удобства использования в первую очередь без учета безопасности. В таких случаях безопасность является необязательным элементом списка пожеланий, который добавляется в конце, что на самом деле вовсе не является безопасностью.   -  person    schedule 26.04.2010
comment
@James Westgate 1) AJAX никоим образом не изолирован. Единственная безопасность, применяемая к JavaScript, — это та же концепция происхождения, которая не применяется к XMLHttpRequest, поэтому AJAX не имеет модели безопасности. С Flash нет никакой разницы, так как Flash использует ActionScript, который по сути является JavaScript. Единственная разница между Flash и JavaScript заключается в том, что Flash компилируется. 2) AJAX не имеет модели безопасности, и нет никаких гарантий, что он не будет использоваться злонамеренно или в качестве маяка для неквалифицированных третьих лиц. Единственные уведомления, которые я видел, находятся в Firebug и не являются ошибками.   -  person    schedule 26.04.2010
comment
@jah Возможно, я не прав, но пока никто не предложил решение проблемы безопасности. Либо примите мое решение, либо предложите лучшее.   -  person    schedule 26.04.2010
comment
@Остин. Я не согласен с тобой. Вы не можете перечислить файлы пользователя с помощью javascript - точка. Может я вас не правильно понимаю.   -  person James Westgate    schedule 27.04.2010
comment
@James Westgate Я не понимаю, что вы имеете в виду, когда перечисляете файлы пользователя с помощью JavaScript.   -  person    schedule 27.04.2010
comment
@Остин. Доступ к файловой системе на клиенте. По сути, выход за пределы песочницы.   -  person James Westgate    schedule 27.04.2010
comment
@James Westgate Программный код должен иметь доступ к файловой системе клиента только за пределами сетевого интерфейса. Это, пожалуй, самая большая проблема с ActiveX. Я должен был прямо затронуть эту проблему в своей статье. Похоже, пришло время для обновления.   -  person    schedule 27.04.2010
comment
@Остин. 1. stackoverflow.com/questions/1087246/. Нет доступа через javascript. 2. blog.chromium.org/2008/ 10/. Браузер-песочница.   -  person James Westgate    schedule 27.04.2010
comment
@James Westgate Ваша первая ссылка совершенно не имеет значения, если только вы не путаете JavaScript с Java. Упомянутая технология выглядит как катастрофа в области безопасности. Песочница Chrome, безусловно, является шагом в правильном направлении, но это не технологический стандарт, и у него есть ограничения. Тем не менее, это отличная идея, но мне больше нравится метод прокси, используемый Opera Mini. Идея была бы комбинацией двух, но даже все же это только упреждающее смягчение, а не решение. Правило, упомянутое в моей статье, остается в силе. Если бы безопасность была на первом месте, правилу следовали бы в первую очередь и всегда.   -  person    schedule 27.04.2010
comment
@Остин. Мне придется с вами не согласиться. Удачи с вашей бумагой.   -  person James Westgate    schedule 27.04.2010
comment
Единственная безопасность, применяемая к JavaScript, — это та же концепция происхождения, которая не применяется к XMLHttpRequest, поэтому AJAX не имеет модели безопасности. -- SO применяется к XHR.   -  person jah    schedule 28.04.2010

Ответы (2)


arrow_upward
1
arrow_downward

Я бы подумал о варианте №2.

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

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

person timdev    schedule 25.04.2010
comment
Если большая форма должна отображаться, когда JavaScript отключен, как AJAX может быть решением? - person ; 26.04.2010
comment
Очевидно, что javascript не является решением, когда javascript отключен. См. третий абзац ОП. - person timdev; 26.04.2010
comment
Спасибо, тимдев. Таким образом, это будет XHR, который извлечет только элемент <form> и его содержимое? Выполнение всей обработки длинной формы на стороне клиента — это действительно план. - person jah; 26.04.2010
comment
Это в основном то, что я бы сделал, да. $('#formdiv').load('/form.html'); или какой-то вариант (здесь предполагается jQuery) - person timdev; 26.04.2010
comment
Еще раз спасибо timdev - я пойду этим путем! Я собирался спросить, может ли /form.html в вашем примере быть фрагментом кода, а не целой html-страницей, но пример Криса очень хорошо прояснил этот небольшой запрос, поскольку я мог видеть, что запрос XHR возвращает фрагмент кода. - person jah; 26.04.2010
comment
Верно. Вы можете сделать это в любом случае. form.html может содержать только форму, или это может быть страница, которую пользователи без поддержки js могут заполнить, и вы просто вытаскиваете элемент формы. - person timdev; 26.04.2010

arrow_upward
1
arrow_downward

Я использую Colorbox для таких вещей, это действительно хорошо.

Вы можете указать контент внутри или через другой URL-адрес (что я и делаю). Вероятно, лучше использовать этот второй метод, так как он делает вашу веб-страницу намного чище и запрашивает содержимое формы только в случае необходимости. Это также означает, что вы можете отправлять сообщения обратно в эту форму (при необходимости через AJAX), сохраняя весь опыт более чистым.

Проверьте это здесь — нажмите «Отметить этот смайлик». Форма берется с удаленного URL-адреса и отправляется обратно в форму с помощью jQuery. Это, очевидно, простая версия того, что вы хотите, но работает и выглядит очень красиво.

Для вашего сценария, когда вам нужен достойный запасной вариант для пользователей без javascript, у меня была бы форма на веб-странице, но скрытая с помощью javascript, а затем используйте Colorbox для загрузки этого содержимого для всплывающего окна, когда это необходимо.

person Chris    schedule 25.04.2010
comment
Спасибо, Крис. Colorbox может быть или не быть излишним для этого проекта, но режим работы именно то, что мне нужно - запрос контента для заполнения оверлея. Ваш пример помог мне понять, что запрошенный контент не обязательно должен быть целой страницей. - person jah; 26.04.2010