You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Val Blant (JIRA)" <de...@myfaces.apache.org> on 2007/11/01 00:51:51 UTC
[jira] Issue Comment Edited: (TOMAHAWK-1139) A new approach to JSF
error handling
[ https://issues.apache.org/jira/browse/TOMAHAWK-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539216 ]
vace117 edited comment on TOMAHAWK-1139 at 10/31/07 4:51 PM:
---------------------------------------------------------------
The idea is as such:
MDF provides more flexible message decoration by adapting the opposite approach to the one used by JSF:
1) Message decoration is decentralized. MDF wraps converters and validators on individual input fields and performs message text replacement right on the spot in the PROCESS_VALIDATIONS phase, when all of the pertinent data for resolving the label text is still available.(i.e the components in data tables would still have the correct values for the current row being validated)
2) The label text to be used is specified by the input field, not the label. This allows the developer to reference any text value, instead of tying them to a specific label component.
Pictures are better than words, so here is an architectural diagram:
http://www.imagehosting.com/out.php/i1259440_ArchitectureDiagram.png
(the same image is also attached)
The framework consists of two main classes, ConverterMessageDecorator and ValidatorMessageDecorator. I will just talk about the converter part, b/c the validator part is very similar but wraps a list of validators instead of one converter.
So ConverterMessageDecorator is a JSF converter. Its purpose is to wrap the converter that is going to do the actual conversion work and decorate the FacesMessage inside ConverterException if one was thrown. The converter to wrap can be either determined automatically based on the type of the value reference of the input field or specified explicitly. This converter decorates the message by replacing all instances of the input field's id with the resolved label text. The power of this approach is that not only do you get a much more flexible way to specify what the label text is (either fieldLabel or fieldLabelComponent attributes), but now data tables are no longer a problem.
Here are some usage examples:
<h:inputText value='#{section33SetupBackingBean.contribution.sampleGatePct}'>
<md:decorateConverterMessage fieldLabel='#{msgs["section.34.setup.contribution.initial.sampling.gate.max.size"]}' />
</h:inputText>
...etc...
<h:inputText
value='#{section33SetupBackingBean.payment.sampleGatePct}'>
<md:decorateConverterMessage fieldLabel='#{msgs["section.34.setup.payment.initial.sampling.gate.max.size"]}' />
</h:inputText>
The two input fields have exactly the same labels on the screen (they are in two different parts of the page), so if we used their respective labels, the error messages would look the same for these two input fields. More complicated example:
<h:dataTable value="#{paymentCalcBackingBean.currentPaymentPercentages}" var="currentPercentage" >
<h:column>
<ops:refDataDescription id="provinceLabelTextId" refDataType="provinceStateType"
code="${currentPercentage.programProvince.provinceStateTypeCode}" />
</h:column>
<h:column>
<h:inputText value="${currentPercentage.federalPercentage}">
<md:decorateConverterMessage fieldLabelComponent="provinceLabelTextId" valueRequired="true" >
<f:converter converterId="ops.PercentageConverter" />
</md:decorateConverterMessage>
<md:decorateValidatorMessage fieldLabelComponent="provinceLabelTextId">
<f:validator validatorId="ops.PercentageValidator" />
</md:decorateValidatorMessage>
</h:column>
...etc...
</h:dataTable>
This would produce errors shown in this screen shot:
http://www.imagehosting.com/out.php/i1259418_Example3.png
Here is another example that shows off what you can do by referencing other ValueHolders on the page.
The code is exactly the same as the snippet shown above, but the inputText component is referencing a text box, so the label text is going to be whatever the user types into the text box:
http://www.imagehosting.com/out.php/i1259467_Example4.png
was (Author: vace117):
The idea is as such:
MDF provides more flexible message decoration by adapting the opposite approach to the one used by JSF:
1) Message decoration is decentralized. MDF wraps converters and validators on individual input fields and performs message text replacement right on the spot in the PROCESS_VALIDATIONS phase, when all of the pertinent data for resolving the label text is still available.(i.e the components in data tables would still have the correct values for the current row being validated)
2) The label text to be used is specified by the input field, not the label. This allows the developer to reference any text value, instead of tying them to a specific label component.
Pictures are better than words, so here is an architectural diagram:
http://www.imagehosting.com/out.php/i1259440_ArchitectureDiagram.png
The framework consists of two main classes, ConverterMessageDecorator and ValidatorMessageDecorator. I will just talk about the converter part, b/c the validator part is very similar but wraps a list of validators instead of one converter.
So ConverterMessageDecorator is a JSF converter. Its purpose is to wrap the converter that is going to do the actual conversion work and decorate the FacesMessage inside ConverterException if one was thrown. The converter to wrap can be either determined automatically based on the type of the value reference of the input field or specified explicitly. This converter decorates the message by replacing all instances of the input field's id with the resolved label text. The power of this approach is that not only do you get a much more flexible way to specify what the label text is (either fieldLabel or fieldLabelComponent attributes), but now data tables are no longer a problem.
Here are some usage examples:
<h:inputText value='#{section33SetupBackingBean.contribution.sampleGatePct}'>
<md:decorateConverterMessage fieldLabel='#{msgs["section.34.setup.contribution.initial.sampling.gate.max.size"]}' />
</h:inputText>
...etc...
<h:inputText
value='#{section33SetupBackingBean.payment.sampleGatePct}'>
<md:decorateConverterMessage fieldLabel='#{msgs["section.34.setup.payment.initial.sampling.gate.max.size"]}' />
</h:inputText>
The two input fields have exactly the same labels on the screen (they are in two different parts of the page), so if we used their respective labels, the error messages would look the same for these two input fields. More complicated example:
<h:dataTable value="#{paymentCalcBackingBean.currentPaymentPercentages}" var="currentPercentage" >
<h:column>
<ops:refDataDescription id="provinceLabelTextId" refDataType="provinceStateType"
code="${currentPercentage.programProvince.provinceStateTypeCode}" />
</h:column>
<h:column>
<h:inputText value="${currentPercentage.federalPercentage}">
<md:decorateConverterMessage fieldLabelComponent="provinceLabelTextId" valueRequired="true" >
<f:converter converterId="ops.PercentageConverter" />
</md:decorateConverterMessage>
<md:decorateValidatorMessage fieldLabelComponent="provinceLabelTextId">
<f:validator validatorId="ops.PercentageValidator" />
</md:decorateValidatorMessage>
</h:column>
...etc...
</h:dataTable>
This would produce errors shown in this screen shot:
http://www.imagehosting.com/out.php/i1259418_Example3.png
Here is another example that shows off what you can do by referencing other ValueHolders on the page.
The code is exactly the same as the snippet shown above, but the inputText component is referencing a text box, so the label text is going to be whatever the user types into the text box:
http://www.imagehosting.com/out.php/i1259467_Example4.png
> A new approach to JSF error handling
> ------------------------------------
>
> Key: TOMAHAWK-1139
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1139
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Reporter: Val Blant
> Attachments: Architecture Diagram.png
>
>
> I discussed this idea on the developer forum and I got a sense that people think that this would be a useful addition to MyFaces.
> I haven't made a MyFaces specific patch yet, but to track the issue I will reproduce my description of the problem and the solution here. I will also attach a standalone jar that contains the working solution, in case someone want to merge it into the Tomahawk project before I get around to figuring out how to set up a MyFaces development environment and make a proper patch myself (not something I have time for right now).
> Please note that it would be very easy for someone who already has the development environment set up to incorporate these changes in, since there is very little code in the jar and the code is well documented.
> I will outline the problem this is meant to solve in the next comment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.