+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 <[EMAIL PROTECTED]> 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 <[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:
> > >
> > > "<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: [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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
