On 18 Mar 2010, at 23:46, David Connors <[email protected]> wrote:
I swore off web.forms when I first clapped eyes on to it and we have
a couple of frameworks we've been using over the years in lieu of
it. That said, there is a lot of design-goal similarity between ASP.NET
MVC and our own frameworks - so much so that I'm considering
retiring our own stuff in favour of MVC. I did see some features
mentioned in MVC 2 along the lines of client-side model validation
which made my cringe - but
I too am not exactly sure what MVC 2 offers on validation, however, I
believe you can provide metadata/annotations for validation. Not sure
how that propogates to the client side.
Writing validation server-side and the same validation in JavaScript
is a duplication of effort and, for complicated systems, a maintenance/
testing burden.
If a user disables JavaScript (or is running a down-level browser)
then you only get server-side validation.
We're living in a AJAX/jQuery world now and browsers are more capable,
so if scripting is enabled why not pass the user input to the same
server-side validation code?
I've not looked at ASP.NET MVC 2.0 close enough to know whether it
has been wrecked by VB programmers.
Ouch!
As you say, web.form is rubbish. It was designed by idiots who were
trying to map an event-driven vb/vba view of the world onto the
Internet where the underlying technology fundamentally does not work
that way.
And those idiots allowed other idiots to become 'drag and drop/wizard
dependent' developers. Allowing them to develop on a platform/
technology they had no idea how it worked. Stateless, huh? I'll just
put everything into session variables to make it work.
The same people who though of the ingeneous idea of running a
scheduler from Application_Start().
A case in point, I tried to sign up to Windows Phone Marketplace
yesterday: http://developer.windowsphone.com/Default.aspx
The register button just produced a script error in all browsers. I
wonder how many attempted registrations failed as a result? What is
the value of all of the web.forms crap behind the scenes? Nothing.
Just more complexity that gets in the way of the primary function of
the application so someone can do a demo to show that nitwits can
build web sites like VBA.
Doubtless, you'd have this problem more often if your name was
O'Connors or company name was Codify & Chips.
There's always ASP.NET Dynamic Data, which is probably webforms for ex-
Access 'developers' who never got beyond next, next, next, finish.
I'm sure there's a place for these frameworks, but I think one should
understand what goes on under the hood and why they can be bad as much
as good. (eg: viewstate being sizably more than your markup).
<sarcasm>Thank goodness ASP.NET traps 'dodgy' characters like < and
> in user supplied data</sarcasm>
Yup. It is really a very big worry when people writing the framework
can be so fundamentally stupid as to think that avoiding XSS issues
is a function of input, not output.
Just HtmlEncode() when persisting the input. That will make it safe
and save you a heck of a lot of work down the track. ;)
--
David Connors ([email protected])
--
Richard Carde
