Pull to refresh

Comments 46

В PrototypeJS/MooTools есть проверенный временем Form#serialize. Проще его импортнуть, чем свои велосипеды писать.
Prototype/Mootools еще похожи, а вот jQuery совсем не так все делает.
Не знаю, с MooTools и Prototype сталкивался, но достаточно давно, и сейчас проверил — нет там такого функционала.

Ближе всего Prototype — $('testForm').serialize(true), но он спотыкается на массивах объектов (просто массивы обрабатывает нормально).

В mootools получилось что то похожее только через:

var hm = $('testForm').toQueryString();
hm = '{"'+hm+'"}';
hm = hm.replace(/&/g, '","');
hm = hm.replace(/=/g, '":"');
var jsn = JSON.decode(hm);

и то, там тоже самое, что и в jQuery.serializeArray — никаких распихиваний значений по свойствам объектов.

Если знаете — напишите, добавлю в топик.
Не совсем понятно, почему только в json формате.
GET/POST формат key=value&key2=value2 очень даже нужен.
Это не JSON если что. Это просто яваскриптовый Object с данными из формы. А в строку его превратить можно многими способами (в том числе и так).
А что такое json, если это не Javascript object? :)
JSON — некое строковое представление данных, т.е. синтаксис/формат. Кстати, там есть отличия от синтаксиса Javascript, например, строки должны быть обрамлены только двойными кавычками, и наименования полей обязательно строки (http://json.org). Javascript object — это некая область памяти, содержащая данные. Вроде разные вещи?
JSON — Javascript Object Notation. Без сомнения это текстовое представление данных, которое eval-ом превращается в обычный яваскриптовый объект. В этом вся соль и кровь этого формата. Обрамление в кавычки — костыль, который позволяет не вводить сложную логику в вывод, чтобы не было синтаксических ошибок, когда значение пустое (… name: ,).
Либо вы занимаетесь словоблудием, либо реально не понимаете сути. Надеюсь первое, и вы просто решили меня постебать. :)
Я как раз понимаю суть — разницу между объектом и его представлением. Очень надеюсь, что вы не отождествляете эти понятия, а потому сами сможете ответить на вопрос «почему Javascript object ≠ JSON».

Или по Маяковскому, «мы говорим Ленин, подразумеваем — партия, мы говорим партия, подразумеваем — Ленин»?

Вкратце:
  1. // JSON
  2. var json = '{ "foo" : "bar" }';
  3.  
  4. // Object
  5. var obj = {
  6.  "foo" : "bar"
  7. };
  8.  
  9. console.log( typeof json ); // string
  10. console.log( typeof obj ); // object
* This source code was highlighted with Source Code Highlighter.

Разница ведь есть?
Окей. Как я понял вы — типичный формалист. Я тоже любил подловить учительницу в школе подобным образом.
UFO landed and left these words here
предположу, что чел просто не умеет пользоваться hg. первое время тоже так делал, потом разобрался.
Google Code поддерживает ещё SVN.
Все проще — очень строгий прокси.
В jQuery есть метод «serializeArray», то же самое делает
Я так понимаю, что используя метод автора, можно сериализовать вложенные формы. Ну и вообще собирать данные в удобную для использования структуру.
а разве вложенные формы это не смерть осликова?
вложенные формы разве можно делать?
Ну имитировать то можно. Иногда не обойтись же.
Да, часто не обойтись. Но мне почему-то приходилось делать форму где-то в углу и яваскриптом двигать в рантайме на нужное место.
Под имитацией я имел в виду использование, например, div.form вместо form. Может быть я совсем не прав и в чем-то ошибаюсь, буду рад критике.
serializeArray не умеет создавать массивы из инпутов: name=«pictures[]»
В топик добавил. В кратце — serializeArray делает не то же самое.
Не лучше (ну, в моем случае). У меня эти данные уйдут на сервер в виде XML, например, и в случае положительного ответа еще и обновят подгруженный ранее XML, из которого с помощью XSL-трансформации получится HTML, отображаемый пользователю =)
зачем посылать-то xml? o_0"
Таки не надо круглых глаз. Условия такие. Да и почему нет? Это порой удобнее REST'ов бывает, например, если есть MS SQL 2005+ с готовыми эндпойнтами, которые принимают данные в виде XML.
потому что о кешировании не думаете и о кроссдоменных запросах. а предоставлять прямой доступ к базе — вообще жуткое решение.
Кеширование — правы, не думаем.
Кроссдоменные запросы — еще раз правы, тоже не думаем.
Прямой доступ к базе — не надо так категорично ;-)
субд в качестве сервера приложений — это очень негибко.
ИМХО использование точек в имени инпутов из вери вери бед идея.
на одном пхп, свет не сошелся клином.
а точка, это все таки служебный символ во многих языках программирования и не все предусматривают доступ к формам через конструкции типа («name»)[«name»]
использования _ самый оптимальный вариант.
На свидку, перволе что пришло в голову это лебедевский парсер+)., там достаточно простой доступ к пост и гет данным через класс форм, например $form: имя_поля. Далее можно использовать всякие методы типа $form: имя_поля.pos и бла бла.
Кому как (на ASP.MVC очень точки удобны), а потому добавил параметр delimiter — туда любую строчку можно воткнуть, какая больше нравится.
вот за возможность выбора, спасибо.
Да, только тащить hg придется. Я архив не обновлял.
Как-то столкнулся с проблемой сериализации в json (и десериализации обратно) вложенных динамических форм. Тоже писал ненормальный рекурсивный велосипед, но нормального решения в сети так и не нашел. Все мечтаю довести до ума.
www.json.org/js.html — тут есть сериализатор JS объектов в JSON
Или проблема именно в создании объекта из формы?
Да, проблема именно в создании объекта из формы.
Имхо, рекурсия тут совсем не зло. Наиболее понятный способ обхода, вызывается относительно редко, и объем данных тоже не огромный.
Спасибо, уже начал использовать в своем проекте.
=) Пожалуйста. Если что встретите — обязательно пишите, багрепорты сейчас крайне важны, и явные ошибки чиниться будут достаточно быстро.
Only those users with full accounts are able to leave comments. Log in, please.