[
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.
