You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Matthias Wessendorf <ma...@matthias-wessendorf.de> on 2004/11/29 10:50:11 UTC
[validation messages] component_id vs. bad value
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
"sss@hotmail": 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
Javascript Hell
Posted by Sylvain Vieujot <sv...@apache.org>.
Hello everybody,
Right now, some components require you to include some javascript
libraries in your app, and to reference those libraries in your page's
header.
Just for your example webapp, the header looks like that :
<!-- JSCook Menu -->
<script language="JavaScript" src="jscookmenu/JSCookMenu.js" type="text/javascript"></script>
<script language="JavaScript" src="jscookmenu/ThemeOffice/theme.js"></script>
<link rel="stylesheet" href="jscookmenu/ThemeOffice/theme.css" type="text/css">
<script language="JavaScript" src="jscookmenu/ThemeMiniBlack/theme.js"></script>
<link rel="stylesheet" href="jscookmenu/ThemeMiniBlack/theme.css" type="text/css">
<script language="JavaScript" src="jscookmenu/ThemeIE/theme.js"></script>
<link rel="stylesheet" href="jscookmenu/ThemeIE/theme.css" type="text/css">
<script language="JavaScript" src="jscookmenu/ThemePanel/theme.js"></script>
<link rel="stylesheet" href="jscookmenu/ThemePanel/theme.css" type="text/css">
<!-- JSCalendar -->
<script language="JavaScript" src="jscalendar/popcalendar.js" type="text/javascript"></script>
<link rel="stylesheet" href="jscalendar/jscalendar-WH/theme.css" type="text/css">
<link rel="stylesheet" href="jscalendar/jscalendar-DB/theme.css" type="text/css">
<!-- JSPopup -->
<script language="JavaScript" src="jspopup/JSPopup.js" type="text/javascript"></script>
I'm now working on a new component that is javascript intensive too, and
that would require the include of at least 5 other .js files.
I think we should make this transparent to the user by :
1. Including the scripts/css/whatever required in the myfaces.jar
file as resources. So, we are sure we always have the .js file's
version that works, and the developer just needs to include the
myfaces lib. (this will grow a bite the size of the jar though).
2. Have the components load the script/css/whatever in a standard
way so that the page's developer doesn't need to bother, and so
that the script/css/... is only included once in the page.
So, starting to think about a solution for this, here is my first idea :
- Have all those scripts/css/... as resources
- Make an additional servlet that the webapp developper would include in
his web.xml declarations, and that would be invoqued like :
http://my.webserver.com/webapp/myFacesRessource?name=jspopup.js
This is the only thing the webapp developper would have to do
(declare the servlet), but I don't see how we could avoid that
without writing the scripts/css/... into the page.
Writing the scripts/css/... into the page would be bad for
caching, and wouldn't allow us to use standard images with this
facility.
- Have a facility so that the component's renderer can call something
like includeRessourceScriptLibrary(facesContext,"jspopup/JSPopup.js")
(similar helper for css, ...), and the code calling the above servlet is
automatically included in the page.
Any thoughts on this ?
Sylvain.
Re: [validation messages] component_id vs. bad value
Posted by Sylvain Vieujot <sv...@apache.org>.
Thank you Manfred for this info.
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
> >>"sss@hotmail": 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
> >>
> >
Re: [validation messages] component_id vs. bad value
Posted by Manfred Geiler <ma...@apache.org>.
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
>>"sss@hotmail": 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
>>
>
Re: [validation messages] component_id vs. bad value
Posted by Sylvain Vieujot <sv...@apache.org>.
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
> "sss@hotmail": 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