Обновить
32
maxatwork@maxatwork

Пользователь

18
Подписчики
Отправить сообщение
В топик добавил. В кратце — serializeArray делает не то же самое.
JSON — некое строковое представление данных, т.е. синтаксис/формат. Кстати, там есть отличия от синтаксиса Javascript, например, строки должны быть обрамлены только двойными кавычками, и наименования полей обязательно строки (http://json.org). Javascript object — это некая область памяти, содержащая данные. Вроде разные вещи?
Да, выложил код в hg
Не знаю, с 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 — никаких распихиваний значений по свойствам объектов.

Если знаете — напишите, добавлю в топик.
Кому как (на ASP.MVC очень точки удобны), а потому добавил параметр delimiter — туда любую строчку можно воткнуть, какая больше нравится.
Кеширование — правы, не думаем.
Кроссдоменные запросы — еще раз правы, тоже не думаем.
Прямой доступ к базе — не надо так категорично ;-)
Таки не надо круглых глаз. Условия такие. Да и почему нет? Это порой удобнее REST'ов бывает, например, если есть MS SQL 2005+ с готовыми эндпойнтами, которые принимают данные в виде XML.
Имхо, рекурсия тут совсем не зло. Наиболее понятный способ обхода, вызывается относительно редко, и объем данных тоже не огромный.
Все проще — очень строгий прокси.
Не лучше (ну, в моем случае). У меня эти данные уйдут на сервер в виде XML, например, и в случае положительного ответа еще и обновят подгруженный ранее XML, из которого с помощью XSL-трансформации получится HTML, отображаемый пользователю =)
Это не JSON если что. Это просто яваскриптовый Object с данными из формы. А в строку его превратить можно многими способами (в том числе и так).
Prototype/Mootools еще похожи, а вот jQuery совсем не так все делает.
Там вообще верстка радует =)
Статья о поддержке, а там обычно много относительно небольших задач. Для них почасовая оплата (возможно, с предоплаченными часами) работает лучше всех остальных, в которых либо слишком большие накладные расходы (при рассмотрении и оценке каждой задачи отдельно), либо есть риск недооценить объем работы (при фиксированной абонентской плате).

Да, разную стоимость часа для специалистов разной квалификации тоже никто не отменял («по этой задаче — программисту нужен 1 час, верстальщику — полчаса»). Все очень наглядно, а это тоже немаловажный фактор.
Это просто попытка показать, что ошибка остается ошибкой, какие рамки не устанавливай =)
Просто аргументация очень убедительная.
Если его использовать в нас, никто не мешает установить какие-то рамки для внутреннего использования, например в документах писать «ИСЧО», невзирая на правила, действующие в России. И претензии не принимаются, точно так же, как мы не имеем права указывать вам, как говорить о нас.
Если никого не коробит — тогда не понимаю этого зверского украинского хвата за «в». Кстати, девушка учится на филологическом — их учили говорить «на».
Там более, вариант «на Украине» считается правильным В России, а поэтому вряд ли может быть оспорено его использование внутри страны. А вот у нас, в Украине, по-правилам принято говорить «В», без исключений.


Не разбираюсь я в тонкостях украинского языка (который используется на Украине). Да и говорим про русский вроде (кстати, непонятно, с чего вы взяли, что его можно использовать только в России) ;-)

P.S. А знаете, давайте от англоговорящих потребуем говорить «в Украине». А то заколебали со своим «in Ukraine».

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность