You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Kevin Menard <km...@servprise.com> on 2006/11/29 22:30:27 UTC
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:
"<Field> must be a numeric value."
And now is:
"<Field> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Number translator message in 4.1
Posted by Cyrille37 <cy...@gmail.com>.
> "<Field> must be a numeric value."
>
> And now is:
>
> "<Field> 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 :
"<Field> must be a numeric value. Format is #."
A user version should be :
"<Field> must be a numeric value."
With all its localized versions :
"<Field> doit être un nombre."
"<Field> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: Re: Number translator message in 4.1
Posted by Patrick Moore <tr...@gmail.com>.
On 12/5/06, Kevin Menard <km...@servprise.com> wrote:
>
> > -----Original Message-----
> > From: Patrick Moore [mailto:transparentpolitics@gmail.com]
> > 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
Posted by Kevin Menard <km...@servprise.com>.
> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: Re: Number translator message in 4.1
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <km...@servprise.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Re: Re: Number translator message in 4.1
Posted by Kevin Menard <km...@servprise.com>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Re: Re: Number translator message in 4.1
Posted by Kevin Menard <km...@servprise.com>.
> -----Original Message-----
> From: Patrick Moore [mailto:transparentpolitics@gmail.com]
> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: Re: Number translator message in 4.1
Posted by Patrick Moore <tr...@gmail.com>.
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
Posted by Sam Gendler <sg...@ideasculptor.com>.
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 <jk...@gmail.com> 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 <sg...@ideasculptor.com> wrote:
> <snipped>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: Number translator message in 4.1
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <sg...@ideasculptor.com> wrote:
<snipped>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: Number translator message in 4.1
Posted by Sam Gendler <sg...@ideasculptor.com>.
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 to
be able to upgrade and utilize newly available features, but they are
unable to without incurring a cost they don't feel they can pay,
either in money, time, or product stability. That isn't something a
'framework' should be proud of. But given that at least one of the
frameworks you mentioned wasn't even a 1.0 version, it shouldn't have
come as a surprise to the development team, and I'd hope that fact was
on the table before they ever decided to use it. It certainly would
have been a major bulletpoint when deciding on tools if I had been
driving development. It doesn't bother me when dojo makes an api
change, precisely because the thing has a 0.4 version number. I know
when getting into it that that is a risk, and when I accepted dojo
into our codebase, I committed to supporting dojo's api changes within
our own codebase. I have different expactations when using a
framework that is numbered 4.x.
So if Tapestry is going to become an unstable platform, I'm just going
to wind up using something else instead. That's a big waste of
intellectual energy and developer cycles for me and my team, so it is
something I'd prefer to avoid if possible. More importantly, if this
impacts other development teams the way it does mine, then I worry
about the community that supports Tapestry, which, if it goes away,
makes Tapestry a much weaker framework for all but the most
knowledgable users (the developers, mostly). That's fine, but it
defeats the purpose of an application development framework, which is
useless if it doesn't actually assist in application development for
users.
And incidentally, I don't really spend that much time writing these
emails. After 30 years of piano, 15 years of full time computer use,
and 5 years of dvorak keyboarding, I type pretty fast. My emails tend
to get long before I even realize it. Sucks for my readers ;-)
--sam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Number translator message in 4.1
Posted by Ryan Holmes <ry...@hyperstep.com>.
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 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
> room in the design for a revamp in the near future (and possibly
> another one a year later when Tap 5 hits the ether). My bosses want
> to know what the benefit of a framework like tapestry is if any
> workload saved is replaced by constant migration issues. I don't have
> a good answer for them, currently.
>
> On any kind of long-lived service project, there is no option to pick
> a version of the framework and stick with it, since doing so will
> leave the product in the stone age as technology advances or else will
> result in an internal fork of the framework source, thereby giving up
> the advantage of using a 3rd party product to begin with, not to
> mention killing any chance of ever upgrading. Building a website
> which will have static content once the development is complete
> doesn't suffer from this problem, since you just stick with the
> framework you have. But when building a service which will have
> ongoing development for years into the future, not being able to pick
> up point releases without major code incompatibilities becomes a real
> problem. The commerical alternatives offer that kind of backward
> compatibilty. Open source frameworks will have to as well if they
> want to be seriously considered for widespread adoption. And, to my
> mind, an application development framework has to pay attention to
> fundamentals of user interface design as much as the application
> developers do, if not more so, if the framework is truly going to cut
> down on workload.
>
> And at the very least, changes that will result in visible differences
> in a page should be explicitly listed in porting notes somewhere.
> Many of us won't immediately notice that an error message changed, so
> we won't take into account the task of modifying an entire
> application's set of validation messages when scheduling a migration.
> Missing an issue like that can be devastating to a schedule. I
> realize (now) that 4.1 isn't yet a full release, although the tapestry
> website sure seems to imply otherwise. But I sure didn't know that
> the first time I attempted to see what would be involved in migrating
> to 4.1, and there is nothing in the documentation to imply otherwise.
> I doubt any new user coming to tapestry today would discover it until
> they were well into development, unless they happened to stumble into
> one of the undocumented, but well known, bugs and posted a query to
> the list, at which point they'd be told to get the latest developer
> snapshot. That's exactly what happened to me, although I got lucky
> and found a big ol' bug on my very first day, so I didn't get too far
> down the migration path before I stopped and turned around. If tap
> 4.1 is going to be presented to the world as being ready for
> development, then the porting guide should be up-to-date, including
> mentioning the known bugs that require an upgrade to the latest dev
> snapshot. That would at least give framework users a fighting chance.
>
> --sam
>
> On 12/1/06, Patrick Moore <tr...@gmail.com> wrote:
>> 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 <sg...@ideasculptor.com> 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 <jk...@gmail.com> 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 <km...@servprise.com> wrote:
>> > > > Hi,
>> > > >
>> > > > Is there any particular reason why the number format message
>> in the
>> > > > number validator changed in 4.1? It used to be:
>> > > >
>> > > > "<Field> must be a numeric value."
>> > > >
>> > > > And now is:
>> > > >
>> > > > "<Field> 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: users-unsubscribe@tapestry.apache.org
>> > > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > 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: users-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > >
>> > >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: Re: Number translator message in 4.1
Posted by Patrick Moore <tr...@gmail.com>.
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 <sg...@ideasculptor.com> 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 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
> room in the design for a revamp in the near future (and possibly
> another one a year later when Tap 5 hits the ether). My bosses want
> to know what the benefit of a framework like tapestry is if any
> workload saved is replaced by constant migration issues. I don't have
> a good answer for them, currently.
>
> On any kind of long-lived service project, there is no option to pick
> a version of the framework and stick with it, since doing so will
> leave the product in the stone age as technology advances or else will
> result in an internal fork of the framework source, thereby giving up
> the advantage of using a 3rd party product to begin with, not to
> mention killing any chance of ever upgrading. Building a website
> which will have static content once the development is complete
> doesn't suffer from this problem, since you just stick with the
> framework you have. But when building a service which will have
> ongoing development for years into the future, not being able to pick
> up point releases without major code incompatibilities becomes a real
> problem. The commerical alternatives offer that kind of backward
> compatibilty. Open source frameworks will have to as well if they
> want to be seriously considered for widespread adoption. And, to my
> mind, an application development framework has to pay attention to
> fundamentals of user interface design as much as the application
> developers do, if not more so, if the framework is truly going to cut
> down on workload.
>
> And at the very least, changes that will result in visible differences
> in a page should be explicitly listed in porting notes somewhere.
> Many of us won't immediately notice that an error message changed, so
> we won't take into account the task of modifying an entire
> application's set of validation messages when scheduling a migration.
> Missing an issue like that can be devastating to a schedule. I
> realize (now) that 4.1 isn't yet a full release, although the tapestry
> website sure seems to imply otherwise. But I sure didn't know that
> the first time I attempted to see what would be involved in migrating
> to 4.1, and there is nothing in the documentation to imply otherwise.
> I doubt any new user coming to tapestry today would discover it until
> they were well into development, unless they happened to stumble into
> one of the undocumented, but well known, bugs and posted a query to
> the list, at which point they'd be told to get the latest developer
> snapshot. That's exactly what happened to me, although I got lucky
> and found a big ol' bug on my very first day, so I didn't get too far
> down the migration path before I stopped and turned around. If tap
> 4.1 is going to be presented to the world as being ready for
> development, then the porting guide should be up-to-date, including
> mentioning the known bugs that require an upgrade to the latest dev
> snapshot. That would at least give framework users a fighting chance.
>
> --sam
>
> On 12/1/06, Patrick Moore <tr...@gmail.com> wrote:
> > 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 <sg...@ideasculptor.com> 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
>
>
Re: Re: Re: Number translator message in 4.1
Posted by Sam Gendler <sg...@ideasculptor.com>.
> +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
room in the design for a revamp in the near future (and possibly
another one a year later when Tap 5 hits the ether). My bosses want
to know what the benefit of a framework like tapestry is if any
workload saved is replaced by constant migration issues. I don't have
a good answer for them, currently.
On any kind of long-lived service project, there is no option to pick
a version of the framework and stick with it, since doing so will
leave the product in the stone age as technology advances or else will
result in an internal fork of the framework source, thereby giving up
the advantage of using a 3rd party product to begin with, not to
mention killing any chance of ever upgrading. Building a website
which will have static content once the development is complete
doesn't suffer from this problem, since you just stick with the
framework you have. But when building a service which will have
ongoing development for years into the future, not being able to pick
up point releases without major code incompatibilities becomes a real
problem. The commerical alternatives offer that kind of backward
compatibilty. Open source frameworks will have to as well if they
want to be seriously considered for widespread adoption. And, to my
mind, an application development framework has to pay attention to
fundamentals of user interface design as much as the application
developers do, if not more so, if the framework is truly going to cut
down on workload.
And at the very least, changes that will result in visible differences
in a page should be explicitly listed in porting notes somewhere.
Many of us won't immediately notice that an error message changed, so
we won't take into account the task of modifying an entire
application's set of validation messages when scheduling a migration.
Missing an issue like that can be devastating to a schedule. I
realize (now) that 4.1 isn't yet a full release, although the tapestry
website sure seems to imply otherwise. But I sure didn't know that
the first time I attempted to see what would be involved in migrating
to 4.1, and there is nothing in the documentation to imply otherwise.
I doubt any new user coming to tapestry today would discover it until
they were well into development, unless they happened to stumble into
one of the undocumented, but well known, bugs and posted a query to
the list, at which point they'd be told to get the latest developer
snapshot. That's exactly what happened to me, although I got lucky
and found a big ol' bug on my very first day, so I didn't get too far
down the migration path before I stopped and turned around. If tap
4.1 is going to be presented to the world as being ready for
development, then the porting guide should be up-to-date, including
mentioning the known bugs that require an upgrade to the latest dev
snapshot. That would at least give framework users a fighting chance.
--sam
On 12/1/06, Patrick Moore <tr...@gmail.com> wrote:
> 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 <sg...@ideasculptor.com> 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 <jk...@gmail.com> 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 <km...@servprise.com> wrote:
> > > > Hi,
> > > >
> > > > Is there any particular reason why the number format message in the
> > > > number validator changed in 4.1? It used to be:
> > > >
> > > > "<Field> must be a numeric value."
> > > >
> > > > And now is:
> > > >
> > > > "<Field> 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: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: Number translator message in 4.1
Posted by Patrick Moore <tr...@gmail.com>.
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 <sg...@ideasculptor.com> 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 <jk...@gmail.com> 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 <km...@servprise.com> wrote:
> > > Hi,
> > >
> > > Is there any particular reason why the number format message in the
> > > number validator changed in 4.1? It used to be:
> > >
> > > "<Field> must be a numeric value."
> > >
> > > And now is:
> > >
> > > "<Field> 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: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Re: Number translator message in 4.1
Posted by Sam Gendler <sg...@ideasculptor.com>.
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 <jk...@gmail.com> 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 <km...@servprise.com> wrote:
> > Hi,
> >
> > Is there any particular reason why the number format message in the
> > number validator changed in 4.1? It used to be:
> >
> > "<Field> must be a numeric value."
> >
> > And now is:
> >
> > "<Field> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Number translator message in 4.1
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <km...@servprise.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Number translator message in 4.1
Posted by Kevin Menard <km...@servprise.com>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Number translator message in 4.1
Posted by Jesse Kuhnert <jk...@gmail.com>.
*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 <km...@servprise.com> wrote:
> Hi,
>
> Is there any particular reason why the number format message in the
> number validator changed in 4.1? It used to be:
>
> "<Field> must be a numeric value."
>
> And now is:
>
> "<Field> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org