> -----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. 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? > 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. FWIW, this is precisely why I would consider my previous example an unacceptable behavior. > For Jesse, or anyone else should not have to worry about maintaining > precisely the same error message. I would rather have him worry about > fixing bugs, adding documentation, examples, and adding new features. > Take this thread to any other open source project and complain about > a error message changing across versions. I have $5 that it is > ignored or ridiculed. Jesse is certainly free to do whatever he wishes with his time. I submit, however, that this change may very well be a "bug". Moreover, given that he took the time to change it, it seems to me that it may be an important enough issue for him to consider again. Indeed, it seems he's willing to discuss the matter further on the dev list, so I plan on taking the thread there. I wouldn't use the "any other open source project" argument though. There's a reason many of us are using Tapestry and not other open source projects. Much of it has to do with the professionalism shown in the design and maintenance as well as community management. Ultimately, the devs will decide what is worthy of their time. I'll file a JIRA issue. If it's not worthy, they'll resolve it as "invalid" and life will go on. A thread with two sides speculating over what the devs will think is worthwhile, however, is not likely to benefit anyone. -- Kevin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
