В источнике класса AjaxBehaviorRenderer (line 260) есть строка, которая, очевидно, добавляет идентификатор NamingContainer к списку необязательных параметров mojarra.ab(...). Я никогда не попадался, так что я интересно, когда он используется:Когда mojarra добавляет контейнер имен в список необязательных параметров?
RenderKitUtils.appendProperty(ajaxCommand, "com.sun.faces.namingContainerId", namingContainerId, true);
линия 260
На прошлой неделе, работая над spec issue 790, что должно решить a.o. Rendering other form by ajax causes its view state to be lost, how do I add this back?, мне это объяснил Нил Гриффин, парень-портлет.
Похоже, что портлеты могут иметь несколько представлений представлений JSF для одного и того же документа HTML, каждый со своим собственным состоянием представления. В портлетах есть специальный экземпляр UIViewRoot, который реализует NamingContainer. Во время обычного рендеринга все формы, входы и команды будут иметь идентификаторы и имена с префиксом собственного идентификатора клиента. Это будет нормально работать при синхронных обратных передачах. Портлет может таким образом определить точное представление для восстановления.
Однако при асинхронных постбэк, то jsf.js создаст кучу дополнительного АЯКСА конкретных параметров запроса, такие как javax.faces.source, javax.faces.partial.event и т.д. Эти имена параметров запроса не префиксы с видом собственного идентификатором клиента. Поэтому портлет не может связывать их с определенным представлением. Следовательно, impl issue 3031.
Была еще одна проблема идентификации идентификаторов состояний в ответах ajax, которые не были должным образом размещены таким образом. Поэтому реализация портлета должна была настроить частичный автоответчик в так называемом «мосте JSF». Это будет учтено во время реализации спецификации спецификации 790. Вместо того, чтобы обнюхивать «среду портлета», как в текущей реализации, будут проверяться на UIViewRoot instanceof NamingContainer, которые являются более гибкими и независимыми от портлетов. Моджарра-специфический com.sun.faces.namingContainerId также будет удален. Вместо этого это значение будет отображаться до <partial-response id="...">, так что jsf.js может просто извлечь оттуда.
В целом, не важно, если вы ориентируетесь только на сервлет-среды.
По balusC комментарий:
Это интересно только для портлетов на основе приложений (не приложения на основе сервлетов). Я не могу точно объяснить, почему и для чего он используется (портлет/пожизненное число парень может), но специфическая функция портлета называется «namespaced параметров». См. https://web.liferay.com/web/meera.success/blog/-/blogs/liferay-requires-name-spaced-parameters
Это интересно только для приложений на основе портлетов (не для сервлетов). Я не могу точно объяснить, почему и для чего он используется (например, портлет/пожизненный парень), но специфичная для портлета функция называется «параметрами с именами». См. https://web.liferay.com/web/meera.success/blog/-/blogs/liferay-requires-name-spaced-parameters Связанные проблемы: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-861 и https://java.net/jira/browse/JAVASERVERFACES-3031 – BalusC
@BalusC Я помещаю ваш комментарий в качестве ответа. Если вы хотите сделать это сами, просто ответьте, и я приму ваше. Мне не нравятся вопросы, которые все еще открыты – Ced