Итак, позвольте мне начать с того, что я немного разочарован, и поэтому этот пост в блоге может быть тем, о котором я сожалею позже, но я стараюсь быть настолько честным, насколько это возможно, здесь и сейчас, я вроде как о чем-то помечен и я хочу снять это с моей груди. В течение долгого времени у меня было невероятное уважение к тому, как ColdFusion облегчает доступ к данным из клиентского кода (или удаленных серверов). Как бы я ни копал Node.js в наши дни, тот факт, что я могу написать CFC и получить API, который может использоваться JavaScript, чертовски силен. Эта особенность прошла долгий путь. Когда он только вышел, единственным выходом был WDDX. Теперь вы можете выводить что угодно, от WDDX до SOAP, XML, простых строк и, конечно, JSON.
На самом деле, мне настолько нравится эта функция, что я предложил тему для нее на этом саммите ColdFusion этого года . Моя сессия будет обзор того, как генерировать вывод для удаленного потребления и охватывать все от начала (ColdFusion MX и ранее) до следующего выпуска (12).
Однако…
С начала собственной поддержки JSON в ColdFusion (ColdFusion 8) были проблемы с сериализацией. Все это основано на том факте, что переменные ColdFusion не содержат типов, и поэтому сервер должен (или делает это?) Делать предположения о том, как преобразовать значения в JSON. За последние три выпуска я видел множество ошибок и множество исправлений, и хотя у меня не было реальных доказательств (подробнее об этом через минуту), моя интуиция сказала мне, что все немного затухло, и что у ColdFusion 11 это проблема подошла.
Или я так думал.
Оказывается, ошибка 3337394 , созданная почти три года назад, о помеченная как закрытая и исправленная, все еще остается проблемой для сериализации. Если у вас есть данные в структуре, и у них есть строковое значение «Нет», ColdFusion преобразует их в false. Вот образец:
x = {"name":"No"};
y = queryNew("id,name", "integer,varchar", [{"id":1, "name":"ray"},{"id":2, "name":"No"}]);
writeoutput(serializeJSON(x));
writeoutput("
");
writeoutput(serializeJSON(y,"struct"));Что дает вам:
{"name":false}
[{"ID":1,"NAME":"ray"},{"ID":2,"NAME":"No"}]
Как видите, структура нарушена, запрос работает нормально. (Как сообщается в самой ошибке.)
Другая проблема связана со строками, которые содержат числа. Рассмотрим эти два примера:
z = {"productkey":"89900909130939081290830983019819023"};
z2 = queryNew("id,name", "integer,varchar", [{"id":1, "name":"ray"},{"id":2, "name":"89900909130939081290830983019819023"}]);
writeoutput("");
writeoutput(serializeJSON(z));
writeoutput("
");
writeoutput(serializeJSON(z2));Это возвращает:
{"productkey":89900909130939081290830983019819023}
{"COLUMNS":["ID","NAME"],"DATA":[[1,"ray"],[2,"89900909130939081290830983019819023"]]}
Как вы можете видеть, productkey теперь является числом, и оно будет преобразовано в 8.990090913093909e + 34 в JavaScript.
Так…. да уж. Во всех случаях есть обходные пути. Но позвольте мне спросить вас об этом. Вы бы использовали базу данных, которая случайно меняла значения на вас?
Кажется смешным, что это все еще проблема сейчас. Это может быть невероятно сложно. Черт возьми, я не буду притворяться, что смогу решить это. Но вот несколько предложений:
- Очевидно, что команда ColdFusion имеет для этого модульный тест. Они должны. Поэтому, когда обновится юнит-тест для предметов, найденных в баге, поделитесь им с нами. Я знаю, что в сообществе есть много людей, которые бы отдавали свое время, чтобы помочь в проведении модульного теста или, черт возьми, просто провести его локально и проверить, когда появляются новые версии. Итак, это мой первый запрос — давайте посмотрим тесты для сериализации JSON. Говоря о модульных тестах, когда в последний раз эта ошибка была исправлена, почему бы сразу не поделиться тестом? Я имею в виду, мы не увидим это работает, но я обещаюВы, люди, которые спрашивали, почему ошибка, связанная с сериализацией данных, имела тест, который проверял только запросы (и я считаю, что CFC). Я не хочу говорить об инженере, который исправил это — мы все делаем ошибки — но почему бы не опубликовать тест, когда вы пишете его и делитесь им с нами? Конечно, можно написать эссе об отсутствии общения, которое иногда происходит на трекере ошибок, что является настоящим позором. Вы знаете, я понимаю, что некоторые люди не любят заниматься или в основном стесняются. Но этому больше нет оправдания. Я тоже очень стеснительный. Когда кто-то говорит мне, что я должен упорно трудиться, чтобы ответить на их вопросы с вопросами самостоятельно. Я осознаю, что недостаточно вовлечен в общение с людьми, и заставляю себя разбираться с недостатком социальных навыков. Составьте список и поместите его на PostIt рядом с вашим монитором. «Когда я исправляю ошибку,ответьте с подробностями о том, как я это исправил, как я это проверял, и что меня может беспокоить. У репортера может быть хороший вклад! »
- Учитывая, что «клейкий» аспект ColdFusion является одним из главных преимуществ, сделайте сериализацию JSON приоритетом для ColdFusion 12. Очевидно, что проблема еще не решена, что, конечно, хорошо, прошло много лет, но хорошо. Дорожная карта ColdFusion 12 гласит: «Возможность управлять, контролировать, регулировать, защищать веб-службы REST и SOAP — управление API». Прежде чем управлять своими API, я хочу на 100% убедиться, что они действительно обрабатывают данные правильно.
- И эй — как насчет ядерного варианта? Если сама природа переменных ColdFusion означает, что проблема не решаема на 100%, удалите эту функцию. Шутки в сторону. Ладно, может быть, это излишне, но в ColdFusion есть вещи, которые давно не обновлялись, выглядят заброшенными и, возможно, должны быть отброшены. Так что, если они не могут это исправить, удалите это.
Поэтому я начал эту запись в блоге с несколько смелого заголовка — пора ли перестать использовать ColdFusion для удаленных API? Многие из нас в сообществе уже выступали против использования функций ColdFusion UI . Если мы не можем доверять данным, полученным в результате встроенной сериализации JSON CF, то пора ли прекратить их полное использование? Как вы думаете?
ps Не забывайте, что вы можете переключиться на отличный JSONSerializer.cfc Наделя .
ps Сверху я отметил, что ColdFusion должен угадать тип данных. Адам Кэмерон замечательно комментирует в баге следующее: «Вы говорите, здравый смысл, Питер: это неудобно, но понимаете, что CF не может определять типы данных в подобных ситуациях, поэтому — исходя из этого — * не пытайтесь *. Если ты знаешь, что не можешь что-то сделать… не делай этого, и все равно попробуй ». Учитывая, что «Нет» является строкой, не конвертируйте ее. Если кто-то использует Нет для ложных в своих данных, то почему бы не наказать их вместо всех остальных?
ps Когда я писал это, мне пришло в голову, что у нас есть другие места, где вещи становятся немного размытыми с данными. Математика, например, разбивается в больших количествах. Я понимаю , что это вопрос через другие языки, и , конечно , мы не должны удалить арифметическими из ColdFusion из — за него, но он просто чувствует , как другой домен , чем то , что я вижу в JSON сериализации.