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 whole thread started off with a message change. Changing an error > message is not changing an API! No, but it is changing an output contract. Perhaps it was never formally committed to, but any sort of test that checks for the presence of an appropriate error message just broke. Backwards compatibility extends beyond just the Java API and should include any user visible change.
I dIsagree. By this argument: spelling errors, poorly-worded messages, badly-translated messages, and swear words in messages are not allowed to be changed/corrected/removed because it is part of some "contract". If a condition is so important to test against then it is so important to have a custom error message for it. Just to illustrate, I'll go to an extreme. What if the Shell component
suddenly started supplying a default stylesheet that provided a Tapestry logo as your background? It wasn't an API change. Your code still works. Is this expected from your framework though?
Wouldn't break my code, I overrided the default stylesheets, and right now it is just me and one other person working on my project.
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 end-user. To rely on defaults is just asking > for trouble. I would expect the framework to support the 80% use case. I would expect reasonable defaults. The framework should not rely on the developer to override everything to make it consumable by end users. The capability should certainly be there, but the default should be essentially ready for mass consumption.
This is a strawman argument, that is not what I am saying. I am saying that user visible output such as error messages are/should always be customized by end developer. Internal behavior and functionality, should have good defaults. Anyhow, we are going to just have to disagree. If you want to respond to this to get the last word in, you are welcome to but I think I have spent too much time on this myself. -Pat
