John:
I will not disagree regarding that some validation tasks (validation of part
numbers, etc...) cannot be performed client-side but the format thereof
along with certain "illegal" characters certainly can be in most cases. In
my opinion, bad user input should be filtered client-side [whenever
possible] to a.) prevent an unnecessary postback, and b.) prevent bad,
possibly malformed data from being sent to the server if possible.
Furthermore, part of the success/acceptance of any application is the
perception of good performance. If your application can perform at least
most of the validation client-side and therefore prevent some unnecessary
postbacks and server processing, the application will [typically] appear to
the user as being better performing and therefore (whether correctly or not)
perceived to be of higher quality.
In most cases I am all for the most simple solution but there are places
(such as with validation code) where I believe the added complexity will
result in a better overall application and better user experience.
I also disagree with your point regarding two types of "validation feedback"
for users to deal with since if the user has scripting enabled, the
validation code would catch it there and the user would never see the
validation feedback. If the user does not have scripting enabled, the
reverse is true. In situations where the validation can only be performed
server side, writing your code so that the error display follows the same
manner as your client side code would result in a single type of feedback
for users to deal with; just because something has to happen on the server
doesn't mean that is has to look like it.
You're right, client side bugs are a serious risk but that just emphasizes
the need for testing before deployment. Not thoroughly testing code (client
or server side) is nothing short of irresponsible. In my experiences, most
(notice that I said "most") of the script errors on major web sites are not
due to bad scripting work on the part of the site developers but is
typically due to a spyware infection. Tracking client-side bugs is far from
impossible, particularly with the script debugger in VS.
I disagree with your statement about developing for the "constructive
intelligent user" as opposed to the other types you defined. In a perfect
world where everyone would only enter valid input I would be hard-pressed to
come up with counter points but we both know that we're far from that.
Assuming for a moment that all of your users are "constructive intelligent",
people, even the best of us, still make mistakes. Even professional data
entry operators get "fat-fingered" once in a while. Typos are bound to
happen. It is part of our job as professional developers to anticipate what
can go wrong and where. One must assume that anywhere someone can enter
something, that something may be wrong. My philosophy does not extend to
categorizing my users, it simply assumes that users will enter invalid data
that must be accounted for. It is especially important to guard against
your "destructive user" class because these are the ones that will cause the
majority of the problems when the data is not properly checked.
You're absolutely correct in that writing a regular expression for parsing
truly valid date would be nearly impossible to write but when it comes down
to it, a regex is not the correct tool for truly validating a date. Regexs
are meant for pattern matching and they're very good at it. If you're
working on an app that requires a particular format for a date, check that
on the client and let a date parser do the full check where appropriate.
You could even just check the format on the client and let your chosen date
parser do a full check server side, bypassing the formatting check if you're
worried about the [negligable] performance hit from doing both server side.
I did some informal performance tests between the DateTime.Parse() and
Regex.IsMatch() just out of curiosity and found the performance difference
between simply using the DateTime.Parse() and running Regex.IsMatch()
immediately before parsing to be so negligable that even under intense
traffic, the impact probably wouldn't even be noticed.
Not all applications can be written for low speed connections. As an
example, one of the systems that I work on transmits CAD data to our
suppliers. Even zipped, these files are often in excess of 30MB which, at
14.4 takes an estimated 5 hours to complete assuming that the connection
isn't dropped at any time during the transfer. CSS can also make for a
"pretty" site that loads quickly, especially once the stylesheet is cached.
My job is not to make money, making money is my goal. My job (how I go
about achieving my goal) is to produce quality software for my client
whether the client is my full-time employer or a side project. I make more
money when I produce quality software than if I produce poor software or no
software. If I reduce my quality standards or quit making software, I need
a new method to achieve my goal.
---
Now, I prefer to give people the benefit of the doubt but since you brought
up the topic of you being a troll, honestly the idea has crossed my mind. I
believe that you do have some good points in many of your posts and are
capable of adding valuable information to the community (I've seen examples
of it) but posting irrelevant links, insulting people, and trying (at all
costs) to convince people of your intellect and worth as a developer is not
the way to (sorry for the cliche) "win friends and influence people." These
rants about how ASP.NET is "broken," duel challenges, and posts filled with
"ha ha ha ha" because you disagree with the design or methodologies are
unacceptable to the community at large.
When people post a issue, they are not looking to be insulted with comments
like "have you tried balancing it on your head," "delete the data in the
production database then it will run faster," or links to rabid singing
gerbils(?) or McDonalds despite how funny you think they may be (most people
won't see it that way). One must keep in mind that not everyone posting
here is a programmer by trade or even wants to be one for that matter. In
many cases, someone is writing software not because s/he wants to but
because the boss wants the software written and told the person to do it.
Others are simply people trying to get into programming (or the specific
technology) and are just looking for advice on where to begin or
clarification on something that has them bewildered. Many people just want
to get their job done and don't care or even want to know about the low
level details of HTTP, etc...
In fact, most people here aren't looking for a debate either (though they'll
be certain to argue if given reason). The frequent contributors here are
all donating their [hopefully] valuable time to benefit others by sharing
their knowledge. One can learn a lot from reading the posts from the highly
knowledgable people such as Juan Llibre, Steve Orr, Brock Allen, and Kevin
Spencer to name a few (sorry to anyone I missed, these are the names that
immediately come to mind). Their methodologies may not be ones that you
would adopt but they are certainly valid, proven, and help people do their
job.
If you have something to contribute that can benefit the community at large
then by all means, please do so. If, however, you feel it necessary to
resort to behavior such as what I listed above, please go elsewhere or be
prepared to be disrespected, disregarded, and flat out ignored, particularly
by the knowledgable people that frequently contribute valuable information
to the discussions on this group.
One of my favorite sayings is "if all you have is a hammer, everything looks
like a nail," I think this fits system architecture perfectly in that it
all boils down to using the right tool for the job. Right tool doesn't have
to be the same tool for everyone either. If you think that traditional ASP
(or a similar technology like PHP) is the correct tool and methodology to do
your job then, by all means, use it to do your job but do not expect that
those that have adopted a different technology and/or methodology to agree.
;)
I won't claim to be the best or most knowledgable programmer in the world.
I won't even claim that my methodologies are the best way to do something.
What I do is share what I know and what has worked for me in my projects.
If I learn something new in the process (a regular occurance), more power to
me.
Regards,
Dave Fancher
http://www.davefancher.com