A new approach to JSF error handling?

Question

Hi.
I would like to run an idea by the community to check that I am not being crazy in doing this stuff. I would appreciate any comments, criticism or ideas.
I was thinking about JSF's error processing mechanism, specifically about how label text gets associated with an input field. So, I am talking about this kind of stuff:
<h:outputLabel for="firstName" value='#{msgs["applicant.search.firstName"]}: ' />
<h:inputText id="firstName" value='#{applicantDetailsBackingBean.firstName}' required=�true�/>If the value is not entered into the input field, we will get an error message saying:
�First Name�: is required.
So HtmlMessageRenderer has replaced the field id in the FacesMessage with the label text by using the association set up with the 'for' attribute on the label. All of this message "decoration" work happens in the RENDER phase in a centralized location. I see a couple of weaknesses in this approach
1) It is too late for resolving label text data if the label is inside a data table
2) JSF establishes associations between label text and the input fields by using the label components to point to their input fields. Although this seems more natural, it limits label text sources to just the label components present on the current page (or whatever is nested under them), which makes it impossible to associate input field messages with label text that does not exist on the page in its entirety.
Let's look at a couple examples, both of which I ran into in my application:
1) Consider a situation in which we have a dataTable where every row consists of a student name and an input field for entering their assignment mark. The validation on the input field will be restricted to valid letter grades only. If the user enters an invalid grade, we want them to see an error message of the form: +�The mark entered for <student name> is invalid�.+ Since <student name> is dependent on the row in which the error occurred, this error message is not possible to generate with bare JSF functionality.
2) Another situation that gets us in trouble is when the label text we want in our error message is not on the page (or not in it's entirety). For example, your page could be split up into multiple parts with those parts having input fields with the same name. We would want the error message to include the page part as well as the field name. This is not easily achieved with the bare JSF functionality.
So to generalize, any situation where a label component with a static value throughout the lifecycle is not available will cause difficulty.
Please correct me if I am wrong on any of these points.
Since in my app I had a lot of complicated pages to deal with, I solved my difficulties by writing a very simple framework that I called Message Decorator Framework (MDF). It enabled me to easily construct much more detailed error messages than what the standard JSF approach seems to allows for. MDF provides a mechanism to specify the label text to be applied to a validation or a conversion message by either a literal, an el expression or via an id of another ValueHolder and all of these work in data tables.
The idea is a s such, and this is what i would like your opinion on:
MDF provides more flexible message decoration by adapting the opposite approach to the one used by the 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 screenshot: 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
Does this approach seem reasonable to people, or am I reinventing the wheel? Please let me know.
Val

Answer 1

Try restarting the DTR application and see if the problem persists.