[
https://issues.apache.org/jira/browse/TOMAHAWK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583508#action_12583508
]
Ernst Fastl commented on TOMAHAWK-1215:
---------------------------------------
At first I'd like to point out, that this is just a simple first shot and not
the complete solution yet.
For simple cases the replaceMessages="id,id,id" parameter can be used a thought
above.
Seeing recent solutions indicate that we might deside to use custom lifecycles
in PPR soon to only execute validation and conversion
for component subtrees which are included in the PPR response IMO we need
option 2 appendMessages="id,id,id".
(I also think something like partial tree lifecycles will come in JSF 2.0)
If you have 2 subsequent PPR responses:
-the first one executes the lifecycle for components A, and B and generates
messages for those
-the second one executes the lifecycle for components C and D and also
generates messages
you might not want to "erase" the messages for A and B by the second response.
Also for the queing feature the need to display messages from multiple request
at once has been expressed if I remember correctly.
So I think messages have to be treated differently than other components.
For the simple replace markup one the user could just wrap the messages in a
PPRPanelGroup.
What we could use there is an alwaysUpdate="true" parameter which simple
includes updates for that component in any PPR
response done for any other PPRPanelGroups on the page.
as for the externalComponents="id,id,id" option - I think that would lead to
some trouble
1. We cannot add the append or replace or any other PPR parameters to just all
other components
2. the way we update markup using innerHtml only works for components which
-a. render only a single parent DOM element (like the span from the
PPRPanelGroup)
-b. do not have any style attributes on those elements
To support extenalComponents="id,id,id" we would need to support all types of
components which is
really not that easy as it may sound - if anyone has ideas how to do that on
the client side please tell
As for the styling - style and styleClass should be easy to include. More
difficult is the message format and the messages
to which the messages-component listens. Therefore it would have been necessary
to duplicate code from the messages-renderer
which I really would like to avoid.
I think the next step here is to extract the code which is responsible for
identifying the messages for a messages component
and format them correctly in some utils class which is then used by PPR and the
messgages renderer.
> Add a communication channel for FacesMessages to the PPRPanelGroup
> ------------------------------------------------------------------
>
> Key: TOMAHAWK-1215
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1215
> Project: MyFaces Tomahawk
> Issue Type: New Feature
> Components: PPRPanelGroup
> Reporter: Ernst Fastl
> Assignee: Ernst Fastl
> Fix For: 1.1.7-SNAPSHOT
>
>
> As any conventional JSF request PPR requests can lead to conversion and
> validation errors or other
> events which produce FacesMessages. The PPRPanelGroup should be enhanced to
> transport
> these messages in a separate channel (meaning a different type of child
> element in the xml-response).
> Optionally a messages-component could be build to which these messages can
> subsequently be added.
> Since this component might collect a lot of messages over various PPR
> requests it could have
> a clear button or something similar which enables the user to clear the
> messages
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
