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
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
