Does it mean that h:message doesn't use the label for {0} when there is one ?
Is it the way to do it in the specs, or could we just enhance the h:message, so that it behaves as the x:message for this matter ?
Sylvain.
On Tue, 2004-11-30 at 17:06 +0100, Manfred Geiler wrote:
Matthias, Sylvain,
Please note that the <x:message> and <x:messages> tags already address
some of your issues.
See myfaces_ext.tld for docs:
8X----------------------------------------------------
<attribute>
<name>summaryFormat</name>
<required>false</required>
<rtexprvalue>false</rtexprvalue>
<description>
If present, instead of rendering the message summary, a MessageFormat
with this attribute as pattern is created. The format method of this
MessageFormat is called with the message summary as the first argument
and the label of the associated component (if any) as the second
argument. Example: "{0}:"
</description>
</attribute>
<attribute>
<name>detailFormat</name>
<required>false</required>
<rtexprvalue>false</rtexprvalue>
<description>
If present, instead of rendering the message detail, a MessageFormat
with this attribute as pattern is created. The format method of this
MessageFormat is called with the message detail as the first argument
and the label of the associated component (if any) as the second
argument. Example: "The input in field {1} is wrong: {0}"
</description>
</attribute>
8X----------------------------------------------------
HTH,
Manfred
Sylvain Vieujot wrote:
> Hello,
>
> I think that our validation messages should be more consistent and
> understandable than they are now.
>
> Including the field's value is good. Maybe we need to have a way to
> shorten it if it's too long, or just to decide we alway stick to :
> value.length() > 10 ? value.substring(0,10)+"..." : value
> for example.
>
> I think it would also help a lot to include the label's value if a label
> is attached to the field (anyone knows how to do that ?).
>
> So, for me a good example would be :
> FIELD'S_LABEL : "VALUE_SUBSTRING(10)" is not a correct VALIDATOR_TYPE
>
> My point here is that we should have something standard and sensible as
> the messages we have now, with the component's id, and no value are not
> great.
>
> Any thoughts ?
>
> Sylvain.
>
> On Mon, 2004-11-29 at 10:50 +0100, Matthias Wessendorf wrote:
>
>>Hi all,
>>
>>our current solution for validation messages is the following:
>>-user enters bad value.
>>- this message comes up (e.g. for e-mail):
>>"component_id": Value is not a correct email-address."
>>
>>if the developer uses *well named ids* all may be fine.
>>"emailValue": Value is not correct...
>>
>>but on *silly ids* it is not clear to the users.
>>e.g. a: Value is not a correct emial....
>>
>>However, if I changed the messages (on my box) to
>>"[EMAIL PROTECTED]": Value is not a correct email-address.
>>this would be more sensible to the users.
>>What do you think?
>>
>>But how should we handle *required*-messages?
>>the current (on my box) is still
>>"component_id": Value is required.
>>
>>Any ideas?
>>
>>
>>Best regards
>>Mit freundlichen Grüßen
>>--
>>Matthias Weßendorf
>>Aechterhoek 18
>>DE-48282 Emsdetten
>>Germany
>>
>
