Могут ли clientId UIComponent меняться по запросам?

Должен ли я ожидать, что результаты UIComponent#getClientId() могут меняться в течение сеанса пользователя? Я хотел бы сохранить полную ссылку clientId на UIComponent и использовать ее позже.

Когда пользователь добавляет динамический компонент:

myBean.setClientId(composite.getClientId());

Гораздо позже в сеансе, когда пользователь «сохраняет»:

String clientId = myBean.getClientId();
UIComponent composite = view.findComponent(clientId);
  • Может быть, разные реализации JSF не гарантируют одинаковый идентификатор клиента в сеансе?
  • Может быть, динамическое добавление и удаление UIComponents (или прихоти) приведет к тому, что один из контейнеров в пути изменит индекс по запросам?

Я видел этот отличный вопрос и ответ, и я не уверен, что он полностью отвечает на вопрос о сохранении clientId и использовании его несколькими запросами позже в сеансе или в динамической форме: когда-и-как-создается-клиент-в-jsf

Спасибо


components clientid jsf
person AAron    schedule 22.09.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если идентификатор клиента содержит автоматически сгенерированный идентификатор, потому что разработчик не указал фиксированный идентификатор компонента через атрибут id, то нет гарантии, что он будет таким же в другом запросе. Конечно, нет, если дерево компонентов программно управляется библиотеками компонентов или даже вами, путем добавления/удаления компонентов без фиксированного идентификатора. Затем автоматически сгенерированный идентификатор «того же» компонента может измениться в зависимости от положения компонента в общем дереве.

Это не зависит от реализации JSF. Спецификация JSF гарантирует только то, что (сгенерированный) идентификатор клиента будет одинаковым для всего запроса. См. также javadoc:

Возврат этого метода должен быть одним и тем же значением на протяжении всего жизненного цикла экземпляра, за исключением случаев, когда свойство id компонента изменяется или компонент помещается в NamingContainer, идентификатор клиента которого изменяется (например, UIData). Однако даже в этих случаях последовательные вызовы этого метода всегда должны возвращать одно и то же значение.

Экземпляры компонента пользовательского интерфейса ограничены запросом. Таким образом, #{myBean} в вашем примере абсолютно не должен быть в более широкой области, чем область запроса, чтобы гарантировать, что идентификатор клиента может быть повторно использован для поиска именно нужного компонента. Если #{myBean} находится в более широком диапазоне, то технически это будет работать только в том случае, если идентификатор клиента состоит только из фиксированных идентификаторов.

Тем не менее, манипулирование деревом компонентов через Java — плохая идея. Вместо этого используйте JSTL. См. также Как атрибут «привязка» работает в JSF? Когда и как его следует использовать?

person BalusC    schedule 22.09.2015
comment
В настоящее время я использую путь clientId, который не имеет идентификаторов j_idt#, но теперь я думаю, что смогу избежать этой проблемы, сделав свои основные идентификаторы компонентов уникальными и найдя их с помощью root.visitTree() (например: <UINamingContainer id="e9e4c42c-a47e-4687-9a6f-b3141274a194" inView="true" rendered="true" transient="false">). - person AAron; 23.09.2015
comment
Спасибо за советы и подсказки по Java-модифицирующему дереву компонентов. Всегда ищу альтернативные подходы, но в настоящее время я получил чистый/надежный подход, который удовлетворяет моим требованиям. Посмотрю на JSTL, чтобы попытаться понять дизайн, который вы предлагаете. - person AAron; 23.09.2015