Имена Freemarker ".vars" не могут содержать тире?

Question

Мы используем Freemarker версии 2.3.16, и я только что обнаружил странную ошибку в одном из наших приложений. В некоторых наших строках кода продукта это стало символом дефиса. Коды используются для извлечения хэшей локализованного текста из глобальной области видимости, используя .vars.

Уменьшение проблемы привело меня к примеру, который может попробовать каждый:

• ${.vars["foo-bar"]} в шаблоне выводит 0

• ${.vars["foo+bar"]} выходы nullnull

• ${.vars["foobar"]} правильно вызывает исключение InvalidReferenceException

Все три должны вызывать исключения. Вместо этого кажется, что строка параметра .vars оценивается! : - (

http://freemarker.sourceforge.net/docs/app_faq.html#faq_strange_variable_name подразумевает, что это должно работать.

Я видел упоминание об аналогичной проблеме несколько недель назад в списке рассылки Freemarker, и было предложено добавить префикс строки параметра к «@». Это может работать с другими хэшами, но НЕ работает с .vars. Я просто взял рабочий пример (.vars["resources_title"]) и изменил его, чтобы он выдал исключение InvalidReferenceException (.vars["@resources_title"]). Я также попробовал это на ссылке через дефис, и это также бросило исключение.

Обновление до 2.3.18, похоже, не имело значения.

Answer 1

Извините за задержку.После некоторой хорошей помощи в списках рассылки о местах установки точек останова, вот что я написал в список 10 июня:

Короткая история: Это не проблема Freemarker.Скорее всего, команда Struts решила использовать Freemarker для обработки имен .vars как выражений OGNL, и, похоже, нет способа заставить OGNL не их анализировать.Таким образом, в Struts «-» и «+» (и, возможно, другие символы) не могут появляться в именах .vars.

Длинная история ...

• freemarker.core.BuiltinVariable (строка 192) - это место, где Freemarker начинает обрабатывать .vars выражений

• freemarker.core.Environment (строка 1088) передает управление «rootDataModel», которыйКоманда Struts, жестко привязанная к экземпляру org.apache.struts2.views.freemarker.ScopesHashModel

• строки 70 этого класса (использует версию Struts) 2.1.8.1, вызывает "stack.findValue";«стек» был задан как экземпляр com.opensymphony.xwork2.ognl.OgnlValueStack

• в строке 236, и этот класс, в свою очередь, запрашивает экземпляр OgnlUtil для поиска объекта, и именно там имяпредполагается, что это выражение OGNL, и анализируется, превращая «foo-bar» в (foo - bar)

Ни в одной точке пути не существует выбора НЕтрактуйте имя .vars как выражение (комментарий в FreemarkerResult намекает на возможность, но код не выполняется).В теории моя реализация FreemarkerManager могла бы создать вариант ScopesHashModel, но для изменения всех связанных с ним классов потребовалось бы много работы.

(И, похоже, не существуетспособ экранирования символов "-" в выражениях OGNL. Кажется, 5-6 лет назад обсуждалось это, но .... .vars( "foo\\-bar" ) не удается найти "-" после "\", так что предположительно "-" isn 't escapable?)

: - (

Мне не ясно, каков вариант использования для обработки .vars имен как выражений ... но я не думаю, что Struts собираетсячтобы изменить, теперь. Вместо того, чтобы переопределять полдюжины классов Struts, я вместо этого изменил код, который загружает наши ResourceBundles в стек значений: теперь он меняет имена, заменяя "-" и "_", а также мои .vars именаизменяются одинаково в шаблоне и ... тада. работает. Ву.

Answer 2

У меня работает. И, как уже упоминалось в списке рассылки freemarker-user : возможно, вы используете странную модель данных или даже необычную ObjectWrapper. Но подобное обсуждение, вероятно, лучше подходит для списка рассылки freemarker-user ...

Answer 3

Поскольку в версии 2.3.22 freemarker можно использовать точку (.), Знак минуса (-) или двоеточие (:) в имени переменной ( подробности здесь ).

В моем случае это не сработает, если я попытаюсь использовать с freemarker 2.3.21 переменные, такие как:

api["x-link"]

Если я поменяю freemarker на версию 2.3.22, это будет работать.