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
>
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.
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
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
13 matches
Mail list logo
