Re: Re: Re: Number translator message in 4.1
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
RE: Re: Re: Number translator message in 4.1
> 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. Unless of course, you'd rather see this hashed out on the dev list rather than through JIRA. -- Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Number translator message in 4.1
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 maintain. Who am I to question that? 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. On 12/5/06, Kevin Menard <[EMAIL PROTECTED]> wrote: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Re: Number translator message in 4.1
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Re: Number translator message in 4.1
> -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]
Re: Number translator message in 4.1
" 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 : A developper version should be : " must be a numeric value. Format is #." A user version should be : " must be a numeric value." With all its localized versions : " doit être un nombre." " ser um valor numérico." And thanks "again" to all of you for the really great TAPESTRY framework. My learning time on Tapestry is a real pleasure ! Regards, Cyrille - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Number translator message in 4.1
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 end-user. To rely on defaults is just asking for trouble. 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. For the projects I listed, for the most part, they never changed because the existing framework worked good enough. And have a fancy new framework was never worth it - so you would lose the argument about "them wanting to upgrade" - management doesn't care - they care more about the custom features. From my perspective, having a library get too hung up on backward compatibility is an invitation to stagnation. I much rather have a library that is willing to discard old API's (with appropriate intermediate releases, labeling an API as deprecated.) To me that is a sign that the library maintainers recognize when they made an error in the original design and are correcting it. Or maybe the world headed in a different direction and the library needs to adapt to accommodate the new users' needs. New users will not scream on these email lists that a library is too cluttered with defunct or difficult APIs that are maintained only for 'backward' compatability. They will simply go away. I have said all that I can say about this. -Pat
Re: Re: Re: Number translator message in 4.1
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. The validation message change was just one small example that happened to touch on all of those areas. --sam On 12/3/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: 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 especially hard time interpreting hints/feelings/etc so to help me better understand I just need people to be very specific about any problems they encounter. An added bonus would be a few submissions in JIRA to help me remember. (as I'm not currently aware of any such issues filed yet) On 12/3/06, Sam Gendler <[EMAIL PROTECTED]> wrote: -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Number translator message in 4.1
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 definitely not the last you've heard of these kinds of changes. ;) We have a sort of skunkworks project taking hold in the confines of the dojo foundation to help attack usability (for end users of applications) in general, so it's something I'll be attempting to incorporate into Tapestry when possible. I know very little about the area comparatively, but the others involved in the project are really the best the industry has to offer - so it'll be an exciting time in the next few releases. On 12/3/06, Kevin Menard <[EMAIL PROTECTED]> wrote: 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 until they get it > right. I haven't looked at the messages for the other validators, but I think the old message here was pretty clear. "... must be a numeric value" doesn't seem to leave much to the imagination. Perhaps "... must be a number" is a little clearer. "Format is #." doesn't really enhance anything, to me. If I didn't know what a "numeric value" was, I sure as hell am not going to know what "Format is #" means ;-) > Perhaps the messages need to be looked at a little more closely on an > individual basis, or ideally find some way to translate "#" type > number format patterns into a more human friendly message ? Well, while I'm all for improving the user experience, I never really saw a problem with the old validator messages. Given that the new message breaks a bunch of integration tests I have, I'm even against the change ;-) Having said that, if there really was a usability issue with the old ones, I think there is merit in investigating better messages. But, keep in mind that most people will not override these strings, so I'd leave developer help messages out (or have a debug mode toggle). -- Kevin Menard Servprise International WebReboot -- Remote Reboot Without Pulling the Plug 800.832.3823 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Number translator message in 4.1
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 until they get it > right. I haven't looked at the messages for the other validators, but I think the old message here was pretty clear. "... must be a numeric value" doesn't seem to leave much to the imagination. Perhaps "... must be a number" is a little clearer. "Format is #." doesn't really enhance anything, to me. If I didn't know what a "numeric value" was, I sure as hell am not going to know what "Format is #" means ;-) > Perhaps the messages need to be looked at a little more closely on an > individual basis, or ideally find some way to translate "#" type > number format patterns into a more human friendly message ? Well, while I'm all for improving the user experience, I never really saw a problem with the old validator messages. Given that the new message breaks a bunch of integration tests I have, I'm even against the change ;-) Having said that, if there really was a usability issue with the old ones, I think there is merit in investigating better messages. But, keep in mind that most people will not override these strings, so I'd leave developer help messages out (or have a debug mode toggle). -- Kevin Menard Servprise International WebReboot -- Remote Reboot Without Pulling the Plug 800.832.3823 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Number translator message in 4.1
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 especially hard time interpreting hints/feelings/etc so to help me better understand I just need people to be very specific about any problems they encounter. An added bonus would be a few submissions in JIRA to help me remember. (as I'm not currently aware of any such issues filed yet) On 12/3/06, Sam Gendler <[EMAIL PROTECTED]> wrote: -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Number translator message in 4.1
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 of Tapestry messages were end-user friendly enough to be used as-is AND they were already internationalized into a number of useful languages. It is pretty unlikely that there aren't large numbers of users using the default messages, precisely because they used to be more than up to the task. Again, the issue is an UNNECESSARY change in behaviour on a point release without any kind of backwards compatibility mode. And on that point, most commerical and many open source frameworks most certainly do go out of their way to provide such stability across releases. Traditionally, version numbering itself was intended to be used to indicate this. API changes generally are reserved for major version changes. The importance of adhering to this is that even the non-technical members of a development team understand this point, so it is always surprising to them that there is as much work involved in upgrading from 4.0 to 4.1 as there is. Incidentally, no one is asking open source to be free. I've been building software based on open and closed software packages for 15+ years (soft. architect or senior developer at Cisco, Akamai, Software.com/Openwave, Dreamworks, Valueclick, the UN, developer at various others), and I am well aware of what open source offers compared to commercial packages. In fact, when I was choosing Tapestry over various and sundry other frameworks, one of the things that drove me to Tapestry was the maturity and stability of the codebase. I went out of my way to look at the differences between 3 and 4 specifically so I could see what I could expect during a major version upgrade, and I liked what I saw. The API remained largely consistent, the changes in the API were well documented and, more importantly, well-justified. And perhaps most importantly, it seemed to have a supportive _community_ of developers who use it, which, as we all know, is usually the single most important factor in the usability of an open source package since the documentation is almost always greviously deficient in open source projects (although tap is better than most in that regard). As a member of that community, I think it is our responsibility to express our opinion of the direction the product is taking. HLS and other developers don't have to pay us the slightest bit of attention, of course, but if the community doesn't express a preference, what we wind up with is a framework that caters only to the unique needs of the developers which can often be fairly out of sync with what a more 'average' user requires, specifically because the developers have such deep familiarity with the API. The 'feature' in question is a nice example. It benefits a small number of users at the expense of what I imagine is the majority. So yes, I see Tap 4.1 as something of a 'Jesse special' which provides some of the changes he most wants to see, potentially at the expense of general usability of the framework for others. That's his perogative, of course, so long as the other developers agree, and I don't read the developer list often enough to be even slightly aware of what the developer process is like on Tap. Unfortunately, I don't have the cycles right now to jump in and start hacking on the tapestry source myself right now, especially 4.1, since I'm not using it. However, as a potential user, I certainly want to speak up and attempt to be heard so that 4.1 can be the best possible upgrade for Tapestry users of all stripes. Open source may not promise a no-cost platform for users, but the concept of an application development framework should promise a certain amount of stability, since its entire reason for being is to ease the development process. When was the last time the gnu C library released an API that wasn't source compatible with previous versions? What about the JDK? I actually think that a framework like Tapestry benefits by not adhering to old api in every case. The benefits of the change often outweigh the cost. But this isn't one of those cases. Not only are the benefits questionable for many users, but it shouldn't be difficult to provide support for users the old api as well. Trading application complexity for an unstable framework isn't a useful tradeoff for anyone, unless you are able to abandon development of projects built on older versions. Forking the framework source is just as inefficient as building your own framework and simply living within its limits isn't often a viable solution for long term devlopment. Listing projects that got stuck on old platforms due to platform instability doesn't support your argument. It reinforces mine. I'm sure the folks at the companies you listed would prefer t
Re: Number translator message in 4.1
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 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 parse a standard Java format mask and presenting one to them will only confuse them. It helps a developer, sure, but applications are for end-users, not developers. You always have the option to include a more detailed message if you care. In the context of going from one 4.x release to another 4.x release, I don't think it is appropriate to include _unnecessary_ features that make the codebase lose backwards compatibility. Admittedly, Tap 4.1 really should be labelled tap 5, given the volume of changes to the api, but so long as it is labelled 4.1, I think an effort should be made to keep changes limited to things that don't destabilize the api unless absolutely necessary. In this case, we are talking about adding end-user visible features that are really only usable, in their default form, by developers. At least the old message could be used in an end-user visbile location. Now, every single validator will require a custom message override, either to restore the functionality of 4.0.x or to provide a message that isn't going to confuse the hell out of a non-technical end user. Sure, the new message is better for a developer when debugging, but since when does convenience stop with the developer rather than the end-user? At least give developers an override that will restore the original messages (Isn't hivemind supposed to make this easy?). Sure it is more work for the framework developers, but that's the point of a framework - to centralize the development effort in the framework itself, making it easier for users of the framework to utilize the provided functionality and cutting down on the total number of developer hours required to develop code. API changes like this are creating unnecessary work for the framework users, which kind of defeats the purpose of using a framework. The effort required to port an application of any complexity from 4.0.x to 4.1 is already very large. I think an effort should be made to keep such changes to a minimum or provide a backwards compatibility layer, preferably one that can be applied on a per-page basis so that migration can be gradual, if at all possible. I don't know about your projects, but this isn't just a matter of getting permission from a PM to change the message. No PM with even the slightest regard for an end user would let a message with a format string specified as a standard java format mask be visible to a non-developer user. If they wanted a message that included the correct format, they would specify it in a form that makes sense to a non-technical user - almost certainly using an example value rather than a format mask - Imagine a european user seeing $#,##0.00 in their error message. Commas and periods would be inverted, the currency symbol is not correct, and what the hell are those '#' symbols doing in there anyway? A change along these lines that would be actually useful and an improvement for the application user, would be the ability to specify an example value and have the validation mask applied to it automatically before it is inserted in the default error message. That way, I could show a european formatted example to european users, and a US formatted one for US users, all while still using the default error message. Now THAT would be useful, and would probably make it past the PM team without requiring a change. THe format mask by itself is useless to anyone but the developer, and you are only getting that by inconveniencing the majority of your current users. A message that is lacking in some information is often preferable to one that contains useless or confusing information, which is how the format mask would be perceived by most end users. It is worth remembering that, while the end user for Tapestry can often be considered the developers who use it, you also have to factor in the audience of users who will use apps developed on Tapestry by those developers. This is a classic example of windows error message syndrome. "An error of type 0x34FD56ABC has occured while processing your input," while useful to a developer, is actually much more frustrating to an end user than "An error has occured while processing your input." Obviously, the ideal is to tell them EXACTLY what went wrong and how to fix it, but failing that, a good design should probably prefer the latter message to the former. For me, it is becoming increasingly difficult to justify our use of Tapestry, except that we are stuck with it short of redeve
Re: Re: Re: Number translator message in 4.1
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 - just makes it possible for me to recognize when I am doing a stupid mistake, as I have so many past mistakes to chose from :-) 4. I am not going to change your mind and you are not likely to change mine. 5. You have spent a long time writing this email and I respect that. 6. Your experience is different than mine. 7. My projects: bunch of no-name start-ups (including my own), IBM, LinkedIn, Ariba ( I am not trying to impress, or more likely not, you just asked about my projects) So my response to the general points End-users will not understand the default message. --- Any message being displayed to the end-users should always be specificed and controlled by the final application developers. No two ways about. Each app is different, both in end-user technicalness and tolerance, no framework can possibly automatically generate the best or even as good an error message as end-users should expect (what I did wrong, how to solve it, link to a more detailed explaination, etc.). This needs to be done anywhy to internationalize/localize an app anyhow. I suppose if an app isn't going to be used by anyone except U.S. english speakers then this can be skipped but forget about selling to any company with a significant overseas work force. Btw. remember that British english is *different* than u.s. english (different definitions for "billion" , color vs. colour, truck vs. lorry, etc.) Default error messages tailored to developers allow for developers to have more time make the app really sing for the end-users. But I don't mean a cryptic "?SYN ERR ON 32" (bonus points if you can figure out where that error message comes from). I mean a message that says exactly what happened, information about how the framework arrived in this unhappy state, etc. The framework's end-users are developers and it should respect their time just as much as my, or your app should respect our end-users time. No migration path/hard to do migration Well, I feel your pain. I really do. All I can say is that this is going to be true pretty much no matter what library/framework you use. Commercial or otherwise. Sure, you can say that microsoft, or some other commercial provider does a better job. But then again you are *paying* them support fees aren't you. If the same amount of money that was paid in support costs to microsoft, sun, etc. was spent to some outside consultancy house I am sure that they would be happy to sweep through an app and do the upgrade. [ In general, I get better support with open-source code I have ever gotten through most commercial providers - but I always risk being told I am an idiot, or being ignored -- worst offenders: Hibernate. ... one of the reasons I am not using Seam nor JBoss. ] Explaining to management the benefits of open source -- Open Source doesn't mean free. (again) Open Source doesn't mean free. Open source costs in terms of learning curve, risk that the code customized to work with/within an open source library will need to be rewritten, etc. The only thing open source means at the end of the day is that *you* have the source code. It doesn't mean an army of willing free developers. Quick question: what happens if HLS gets hit by a truck tomorrow? How about if he goes to the Tibet to discover his navel for a few years? Jesse's plane spirals into the desert? Long-term projects staying techincally up-to-date (and) costs (again) Want to know what LinkedIn is using? JSP 0.92 Ariba? their own version of WebObjects. Ariba is also using "make" not "ant" to do their builds. Want to stay current on any library? It costs. Don't lie to yourself or management that they need to plan for upgrade costs at the beginning. The only (partial) answer is: 1. Lots of automated tests. 2. Isolating "your" code from "theirs" Anyhow, good luck and enjoy your weekend! -Pat On 12/1/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > +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 parse a standard Java format mask and presenting one to them will only confuse them. It helps a developer, sure, but applications are for end-users, not developers. You always have the option to include a more detailed message if you care. In the context of going from one 4.x
Re: Re: Re: Number translator message in 4.1
+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 parse a standard Java format mask and presenting one to them will only confuse them. It helps a developer, sure, but applications are for end-users, not developers. You always have the option to include a more detailed message if you care. In the context of going from one 4.x release to another 4.x release, I don't think it is appropriate to include _unnecessary_ features that make the codebase lose backwards compatibility. Admittedly, Tap 4.1 really should be labelled tap 5, given the volume of changes to the api, but so long as it is labelled 4.1, I think an effort should be made to keep changes limited to things that don't destabilize the api unless absolutely necessary. In this case, we are talking about adding end-user visible features that are really only usable, in their default form, by developers. At least the old message could be used in an end-user visbile location. Now, every single validator will require a custom message override, either to restore the functionality of 4.0.x or to provide a message that isn't going to confuse the hell out of a non-technical end user. Sure, the new message is better for a developer when debugging, but since when does convenience stop with the developer rather than the end-user? At least give developers an override that will restore the original messages (Isn't hivemind supposed to make this easy?). Sure it is more work for the framework developers, but that's the point of a framework - to centralize the development effort in the framework itself, making it easier for users of the framework to utilize the provided functionality and cutting down on the total number of developer hours required to develop code. API changes like this are creating unnecessary work for the framework users, which kind of defeats the purpose of using a framework. The effort required to port an application of any complexity from 4.0.x to 4.1 is already very large. I think an effort should be made to keep such changes to a minimum or provide a backwards compatibility layer, preferably one that can be applied on a per-page basis so that migration can be gradual, if at all possible. I don't know about your projects, but this isn't just a matter of getting permission from a PM to change the message. No PM with even the slightest regard for an end user would let a message with a format string specified as a standard java format mask be visible to a non-developer user. If they wanted a message that included the correct format, they would specify it in a form that makes sense to a non-technical user - almost certainly using an example value rather than a format mask - Imagine a european user seeing $#,##0.00 in their error message. Commas and periods would be inverted, the currency symbol is not correct, and what the hell are those '#' symbols doing in there anyway? A change along these lines that would be actually useful and an improvement for the application user, would be the ability to specify an example value and have the validation mask applied to it automatically before it is inserted in the default error message. That way, I could show a european formatted example to european users, and a US formatted one for US users, all while still using the default error message. Now THAT would be useful, and would probably make it past the PM team without requiring a change. THe format mask by itself is useless to anyone but the developer, and you are only getting that by inconveniencing the majority of your current users. A message that is lacking in some information is often preferable to one that contains useless or confusing information, which is how the format mask would be perceived by most end users. It is worth remembering that, while the end user for Tapestry can often be considered the developers who use it, you also have to factor in the audience of users who will use apps developed on Tapestry by those developers. This is a classic example of windows error message syndrome. "An error of type 0x34FD56ABC has occured while processing your input," while useful to a developer, is actually much more frustrating to an end user than "An error has occured while processing your input." Obviously, the ideal is to tell them EXACTLY what went wrong and how to fix it, but failing that, a good design should probably prefer the latter message to the former. For me, it is becoming increasingly difficult to justify our use of Tapestry, except that we are stuck with it short of redeveloping everything we've already done. More often than not, when I give a design to an engineer, I have to explicitly mention that the current design will be obsolete in the very next version of Tapestry and leave
Re: Re: Number translator message in 4.1
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 hair out over some other issue and the last thing they need from their framework is "Your input is wrong but guess what I am not going to give you a clue on what is the right format (and you can't make me!)". Please, Please, don't be cryptic! +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! -Pat On 12/1/06, Sam Gendler <[EMAIL PROTECTED]> wrote: 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 applications to 4.1 at some point. It seems like a change which isn't _necessary_ and since I use the default message in many cases, I'd actually have to go and override the default message throughout my app when I port it (either that, or get PM to buy into the new text, which would take about 10 times as long). Given that 4.1 isn't _supposed_ to have major upgrade incompatibilities (at least, I'd assume so given the similarity in version number), it'd be nice to keep the messages the same unless absolutely necessary. --sam On 12/1/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > *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 > right. > > Perhaps the messages need to be looked at a little more closely on an > individual basis, or ideally find some way to translate "#" type > number format patterns into a more human friendly message ? > > On 11/29/06, Kevin Menard <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Is there any particular reason why the number format message in the > > number validator changed in 4.1? It used to be: > > > > " must be a numeric value." > > > > And now is: > > > > " must be a numeric value. Format is #." > > > > It's not clear to me that adding this format message is going to be > > beneficial to any of our end users. I'm guessing there's a good reason > > it was added though. I'm just trying to figure out what it may be. > > > > Thanks, > > Kevin > > > > -- > > Kevin Menard > > Servprise International > > WebReboot -- Remote Reboot Without Pulling the Plug > > 800.832.3823 > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tapestry/Dojo/(and a dash of TestNG), team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Number translator message in 4.1
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 applications to 4.1 at some point. It seems like a change which isn't _necessary_ and since I use the default message in many cases, I'd actually have to go and override the default message throughout my app when I port it (either that, or get PM to buy into the new text, which would take about 10 times as long). Given that 4.1 isn't _supposed_ to have major upgrade incompatibilities (at least, I'd assume so given the similarity in version number), it'd be nice to keep the messages the same unless absolutely necessary. --sam On 12/1/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: *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 right. Perhaps the messages need to be looked at a little more closely on an individual basis, or ideally find some way to translate "#" type number format patterns into a more human friendly message ? On 11/29/06, Kevin Menard <[EMAIL PROTECTED]> wrote: > Hi, > > Is there any particular reason why the number format message in the > number validator changed in 4.1? It used to be: > > " must be a numeric value." > > And now is: > > " must be a numeric value. Format is #." > > It's not clear to me that adding this format message is going to be > beneficial to any of our end users. I'm guessing there's a good reason > it was added though. I'm just trying to figure out what it may be. > > Thanks, > Kevin > > -- > Kevin Menard > Servprise International > WebReboot -- Remote Reboot Without Pulling the Plug > 800.832.3823 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Number translator message in 4.1
*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 right. Perhaps the messages need to be looked at a little more closely on an individual basis, or ideally find some way to translate "#" type number format patterns into a more human friendly message ? On 11/29/06, Kevin Menard <[EMAIL PROTECTED]> wrote: Hi, Is there any particular reason why the number format message in the number validator changed in 4.1? It used to be: " must be a numeric value." And now is: " must be a numeric value. Format is #." It's not clear to me that adding this format message is going to be beneficial to any of our end users. I'm guessing there's a good reason it was added though. I'm just trying to figure out what it may be. Thanks, Kevin -- Kevin Menard Servprise International WebReboot -- Remote Reboot Without Pulling the Plug 800.832.3823 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Number translator message in 4.1
Hi, Is there any particular reason why the number format message in the number validator changed in 4.1? It used to be: " must be a numeric value." And now is: " must be a numeric value. Format is #." It's not clear to me that adding this format message is going to be beneficial to any of our end users. I'm guessing there's a good reason it was added though. I'm just trying to figure out what it may be. Thanks, Kevin -- Kevin Menard Servprise International WebReboot -- Remote Reboot Without Pulling the Plug 800.832.3823 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Translator message
Using Tap 4.1 I do not use any validators. How can I make a translator display my own error message in case of translation error ? I try the following : In case of a translation error I get red asterics displayed after my text field, but no trace of any error message. Any advice is appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
