В таком случае отвалится не только этот хак, но и сам обход xml-дерева до нужной ноды, так как имя самой или одной из родительских нод может измениться.
Ребята из Xerox версифицируют свои soap-сервисы, аля /v0/print или /v1/scan, все изменения новой платформы не затрагивают старые методы.
Есть запрос к soap-сервисам, который возвращают несколько десятков килобайт данных о самом МФУ, но из этого набора данных нужна всего лишь информация, поддерживает МФУ листы формата А3 или нет. Такая же история и в момент постановки документа на печать — интересен только статус задачи, а не килобайты балластных для нас данных.
Разумеется это грязный хак, но вынужденный — приоритет находится на стороне потребления памяти, а не красоты и универсальности решения.
Необязательно, можно использовать нативную. Но так как мы не смогли ее полноценно кастомизировать под свои нужды и стили — вынесли в виде отдельной директивы.
Вы несомненно правы, но в нашем случае описанная оптимизация действительно заняла 12-15% от всего времени разработки проекта. А это не может не радовать как глаз, так и бюджет проекта.
В обычной веб-разработке целесообразность не то чтобы нулевая, а скорее отрицательная, так как все параллельные запросы выстроятся в очередь и приложение станет менее отзывчивым. Про потребление памяти XHR тоже не беспокойтесь, а вот контент оптимизируйте.
Если же ваше приложение работает на специфичной платформе с ограниченным количеством ОЗУ, то тут вам повезло — мы собрали грабли и поделились кодом.
Разумеется рассматривали и Angular Light и Vue.js и даже были маниакальные идеи переписать все на чистый JS.
Но отправной точкой послужило почти готовое и протестированное приложение на AngularJS.
С точки зрения рисков, мы оценили, что переписать приложение на другой JS фреймворк против доработать (зарефачить) готовую кодовую базу значительно проигрывает по трудозатратам.
В любом случае, код для http-запросов, роутингу, скролу и т.д. пришлось бы писать свой, а «кастрация» AngualrJS до состояния более легковесных фреймворков занимает, уж поверьте, очень мало времени.
Если же за отправную точку взять старт проекта, то тут разумеется выбор бы пал на Vue.js, сообщество Angular Light показалось нам каким-то полумертвым, а готовых модулей для http-запросов и роутинга днем с огнем не сыщешь.
Ребята из Xerox версифицируют свои soap-сервисы, аля /v0/print или /v1/scan, все изменения новой платформы не затрагивают старые методы.
Разумеется это грязный хак, но вынужденный — приоритет находится на стороне потребления памяти, а не красоты и универсальности решения.
Если же ваше приложение работает на специфичной платформе с ограниченным количеством ОЗУ, то тут вам повезло — мы собрали грабли и поделились кодом.
Но отправной точкой послужило почти готовое и протестированное приложение на AngularJS.
С точки зрения рисков, мы оценили, что переписать приложение на другой JS фреймворк против доработать (зарефачить) готовую кодовую базу значительно проигрывает по трудозатратам.
В любом случае, код для http-запросов, роутингу, скролу и т.д. пришлось бы писать свой, а «кастрация» AngualrJS до состояния более легковесных фреймворков занимает, уж поверьте, очень мало времени.
Если же за отправную точку взять старт проекта, то тут разумеется выбор бы пал на Vue.js, сообщество Angular Light показалось нам каким-то полумертвым, а готовых модулей для http-запросов и роутинга днем с огнем не сыщешь.
Выглядит так:
Некоторые методы soap-сервиса МФУ возвращают в ответ xml со вложенной экранированной xml.