On 12/5/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> -Original Message-
> From: Patrick Moore [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 04, 2006 5:25 PM
> To: Tapestry users
> Subject: Re: Re: Re: Number translator message in 4.1
>
> This whol
> I think they can still be better, but obviously I didn't question my
> changes enough or I would have noticed this issue sooner. It'll be
> reverted soon.
Right. I've opened the JIRA issue per your request. If anyone has any
ideas as to how to improve things, they're welcome to comment. Unle
I really don't know what all of the hub bub is about. I concede that
these messages (at least for numbers) aren't really the best default
for end users - and having good defaults has been one of the core
design patterns that Howard(and the rest of the devs) has obviously
worked very hard to mainta
For all those interested, I've opened up an issue:
https://issues.apache.org/jira/browse/TAPESTRY-1174
I've deliberately not filed it as a "bug" in an attempt to avoid passing
judgment.
--
Kevin Menard
Servprise International
WebReboot -- Remote Reboot Without Pulling the Plug
800.832.3823
-
> -Original Message-
> From: Patrick Moore [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 04, 2006 5:25 PM
> To: Tapestry users
> Subject: Re: Re: Re: Number translator message in 4.1
>
> This whole thread started off with a message change. Changing an error
>
" must be a numeric value."
And now is:
" must be a numeric value. Format is #."
Hello,
my 2 cents in that this long long subject is that there are messages for
developper and messages for user.
I don't know enough Tapestry at the moment, I'm just learning it but my
opinion is that :
Hi Sam --
Well, I don't type nearly as fast. :-)
This whole thread started off with a message change. Changing an error
message is not changing an API! I return to the original statement that the
user of the framework is the developer. And the developer should always
control the output to their
The discussion isn't really about the message changes. It was just
sparked by them. The discussion is about the general philosophy of
framework design, developer vs end-user support, versioning and
backwards compatibility, documentation, and the direction of tapestry
development into the future.
Sure, I can see the validity in the particular case of a simple number
format for numeric values. (except of course what will happen when
they input 3.14 ?)
As I've run out of time to really properly play with these for 4.1.1 I
may have to just revert to the old messages for now, but this is
defi
Thanks for the reply, Jesse.
> I think my original intention was to change some of the default error
> messages to give more specific information about the format that we
> want the input to be in. Rather than just saying "your input sucks,
> try again" and having them randomly type stuff in unti
There certainly is a lot of discussion going on for what my naive mind
sees as only 2-3 validation strings. (which I'd be happy to revert
back to the old way)
If there are other more specific grievances people have I'd love to
hear them. More so than the typical "unsocial nerd" I have an
especial
I disagree with your points regarding validation errors targeting a
developer audience rather than end user. First, validation errors are
not likely to be the result of a programmer error, although yes, if
you do supply the wrong mask, it might prove useful. More
importantly, previous versions o
I agree with Sam's points. The new default messages will be more
confusing to end users and should be reverted, for all of the reasons
Sam mentions.
-Ryan
On Dec 1, 2006, at 6:06 PM, Sam Gendler wrote:
+1 for new extended default messages! It is worth wading through a
sea of
PMs to save d
Hi Sam --
I will preface this by saying:
1. I understand your frustration that there isn't a smooth, clean migration
path to the latest Tapestry.
2. I have worked with a variety of frameworks (open source, free, and
otherwise)
3. I have been coding for a long, long time - doesn't make me right -
+1 for new extended default messages! It is worth wading through a sea of
PMs to save development stress. This is why I like HLS and Tapestry. ... No
(mostly no) cryptic error messages!
You are replacing developer stress with end-user stress. Upir average
end user will not have a clue how to par
Hi Sam --
I, for one, vote that Jesse's extended message is better... The more
meaningful detail that can be provided the better. This is especially true
because it is the default message. The first 'user' to see this message is
the developer. This developer may be in the middle of pulling their
Given that the messages CAN be overridden, I'd like to register a vote
for keeping very simple messages as the default (since I tend to use
them as is) and letting individual users override them as necessary.
Also, keeping the messages unchanged would aid those of us who will
have to port applicat
*meekly raises hand..
I think my original intention was to change some of the default error
messages to give more specific information about the format that we
want the input to be in. Rather than just saying "your input sucks,
try again" and having them randomly type stuff in until they get it
r
18 matches
Mail list logo
