Comments 27
А нету e4x решения?
0
А я написал обертку над MSXML и использую из Javascript, пример кода (jsa — фабрика моих объектов):
// скорректируем манифест на запуск от имени пользователя
manifest = jsa.xml();
manifest.loadXml(jsa.str(jsa.loadRes(app_file, 1, RT_MANIFEST)));
manifest.root.trustInfo.security.requestedPrivileges.requestedExecutionLevel.attr('level') = 'asInvoker';
jsa.updateRes(app_file, RT_MANIFEST, 1, jsa.mbstr(manifest.xml));
т.е. через точечную нотацию я получаю доступ к узлам XML документа — получилось весьма наглядно и удобно.
// скорректируем манифест на запуск от имени пользователя
manifest = jsa.xml();
manifest.loadXml(jsa.str(jsa.loadRes(app_file, 1, RT_MANIFEST)));
manifest.root.trustInfo.security.requestedPrivileges.requestedExecutionLevel.attr('level') = 'asInvoker';
jsa.updateRes(app_file, RT_MANIFEST, 1, jsa.mbstr(manifest.xml));
т.е. через точечную нотацию я получаю доступ к узлам XML документа — получилось весьма наглядно и удобно.
+1
Обёртку в студию! :)
0
Проблема в том, что обертка часть библиотеки классов для работы из скриптовых языков. Написана на Delphi и существует в 2-х видах: как COM-библиотека (использую из Windows script Host) и EXE модуль для создания приложений с логикой на скрипте и без необходимости регистрировать в системе COM-объекты. Вырвать обертку из библиотеки — очень много телодвижений. Были мысли выложить COM-вариант для свободного использования, но нужно писать документацию и сопровождать, а это время.
Да и каждому хочется иметь вариант для своего любимого языка. А мой вариант не каждому подойдет, т.к. точечная нотация основана на IDispatchEx и ее удобно использовать только из скриптовых языков. Т.е. моя обертка не всем подойдет. Вот мне она удобна при написании на скрипте.
По сути эта библиотека своеобразный фреймворк для написания скриптовых приложений с HTML интерфейсом. Типа Adobe AIR — т.е. свой велосипед. Но вот что я заметил, на скрипте с использованием своего фреймворка у меня кода получается писать меньше для реализации некоторой задачи, чем я бы написал кода на самой Дельфе. Т.е. писать получается удобнее. Очень коротко об использовании своей библиотеки я отписался в своем блоге.
Да и каждому хочется иметь вариант для своего любимого языка. А мой вариант не каждому подойдет, т.к. точечная нотация основана на IDispatchEx и ее удобно использовать только из скриптовых языков. Т.е. моя обертка не всем подойдет. Вот мне она удобна при написании на скрипте.
По сути эта библиотека своеобразный фреймворк для написания скриптовых приложений с HTML интерфейсом. Типа Adobe AIR — т.е. свой велосипед. Но вот что я заметил, на скрипте с использованием своего фреймворка у меня кода получается писать меньше для реализации некоторой задачи, чем я бы написал кода на самой Дельфе. Т.е. писать получается удобнее. Очень коротко об использовании своей библиотеки я отписался в своем блоге.
+1
1. Ой, а код чего-то битый… например, в getnodeByPath после условий в if… и вообще много где…
2. Можно было бы использовать ArrayList вместо Vector, чтбы не расходовать ресурсы на синхронизацию — всё равно ведь либа не concurrent-safe.
В целом, удобная обёртка чтобы скрыть все эти factory-buildersю
2. Можно было бы использовать ArrayList вместо Vector, чтбы не расходовать ресурсы на синхронизацию — всё равно ведь либа не concurrent-safe.
В целом, удобная обёртка чтобы скрыть все эти factory-buildersю
+1
>> nodePath.trim().equalsIgnoreCase("") — ????
+1
>> return new String(baos.toByteArray()); — непереносимый код
+1
for(int f = 0; f < bpath.length; ++f) { String c = bpath[f].trim(); if (c != null && c.length() > ) scnt++; }
Зачем мы проверяем c на null? Если бы там был null, то мы бы упали на вызове trim()
Кроме того, я думаю следует быть строже. Если c.length() == 0, то throw new IllegalArgumentException( «illegal path: path components should not be empty» );
+1
Всюду в коде попадается конструкция "} catch (Exception e) { }" — крайне плохо. Не надо ловить всё подряд. Если что-то сломалось — пускай падает. Хоть узнаем сразу, если что-то пойдёт не так. Ну и хоть staack trace показывать надо.
+1
из fromNode
Не помешало бы не делать одно и то же по сто раз, особенно в цикле. Как никак это для телефона, а лишние телодвижения это тормоза и бесценная энергия батареи.
for(int f = ; f < nlc.getLength(); ++f) { if (nlc.item(f).getNodeType() == Node.TEXT_NODE) { .... else nlc.item(f).getNodeType(). .... .... nlc.item(f) ....
Не помешало бы не делать одно и то же по сто раз, особенно в цикле. Как никак это для телефона, а лишние телодвижения это тормоза и бесценная энергия батареи.
+1
Спасибо, я всё учту.
Вообще, некоторая корявость объясняется тем, что не очень вдумчиво переносилось с шарпа. Потому, прошу простить за неидеальный код.
— По поводу "} catch (Exception e) { }".
Я, конечно, понимаю, что это вроде как и неправильно, глушить все ошибки подряд. Но вот моя личная практика топорного программирования показывает, что проще проверить результат на null, а знать, какая ошибка и почему, не совсем обязательно.
Я говорю о моём личном клиническом случае :) Который не обязательно переносить на себя.
Вообще, некоторая корявость объясняется тем, что не очень вдумчиво переносилось с шарпа. Потому, прошу простить за неидеальный код.
— По поводу "} catch (Exception e) { }".
Я, конечно, понимаю, что это вроде как и неправильно, глушить все ошибки подряд. Но вот моя личная практика топорного программирования показывает, что проще проверить результат на null, а знать, какая ошибка и почему, не совсем обязательно.
Я говорю о моём личном клиническом случае :) Который не обязательно переносить на себя.
0
Мега РЕСПЕКТ за этот класс, то что нужно было! Выкладывайте его куда-нибудь и продолжайте развивать, думаю все сталкиваются с тупизмом отсутствия простой работы с XML на Андроиде, в отличии от JSON.
0
Sign up to leave a comment.
Простой класс для работы с XML