Yes, I am using tomahawk 1.1.2. Specifically, I use the <t:messages> tag
to display my errors, which uses
org.apache.myfaces.renderkit.html.ext.HtmlMessagesRenderer.
The code that does the replacement of input field id with the associated
label's value is in
org.apache.myfaces.renderkit.html.ext.HtmlMessagesRenderer. Both
getSummary() and getDetail() methods look up the associated label and
use its value if found...
Why do you think that there should be no error processing?
Val
On Fri, 2007-19-10 at 09:53 +0200, Martin Marinschek wrote:
> You are not reinventing the wheel - first, are you using tomahawk?
> Cause if you use the standard-components you said you use, I wonder
> why you get this error-handling at all, you should only see the client
> id, so like this:
>
> > 'firstName': is required
>
> regards,
>
> Martin
>
>
> On 10/18/07, Val <[EMAIL PROTECTED]> wrote:
> > 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, ideas and whether you think that this approach might be worth
> > including in the MyFaces implementation.
> >
> > 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 of hypothetical examples the kinds 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 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.
> >
> > 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 decided
> > to write 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. All of these work in data tables.
> >
> > The idea is as 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 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
> >
> >
> > Does this approach seem reasonable, or am I reinventing the wheel?
> > Please let me know.
> >
> >
> >
> > Val
> >
> >
> >
>
>
