[
https://issues.apache.org/jira/browse/TOMAHAWK-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539215
]
Val Blant commented on TOMAHAWK-1139:
-------------------------------------
Problem description:
This solution deals with JSF's error processing mechanism, specifically with
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. There are 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 of hypothetical examples:
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 would very hard 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.
To address these issues I wrote a very simple framework that I call 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. All of these work in data tables.
I will describe how it works in the following comment.
> 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
>
> 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.
