Hilarious javascript form abuse



  • I found this awesome login form today that does something new and exciting.

    It takes the username and password fields, and when you click the submit button, it POSTs the result to the server.

    Pretty normal, EXCEPT it uses javascript!

    <script language="javascript" type="text/javascript">
    <!--
    function __doPostBack(eventTarget, eventArgument) {
    var theform;
    if (window.navigator.appName.toLowerCase().indexOf("microsoft") > -1) {
    theform = document.__aspnetForm;
    }
    else {
    theform = document.forms["__aspnetForm"];
    }
    theform.__EVENTTARGET.value = eventTarget.split("$").join(":");
    theform.__EVENTARGUMENT.value = eventArgument;
    theform.submit();
    }
    // -->
    </script>
    <!-- content all up here -->
    <!-- form fields -->
    <a id="_ctl0_bcr_Login1___loginButton" class="CommonTextButton" href="javascript:__doPostBack('ctl0$bcr$Login1$$loginButton','')">Sign in</a>
    I don't really know for sure, but it looks like some MS-generated code
    they put in all ASP sites.  Apparently, HTML isn't good enough anymore.

    Oh yeah this broken-ass abuse is from http://thedailywtf.com/login.aspx which wouldn't let me log in from one of my browsers.



  • @BonzoESC said:

    I found this awesome login form today that does something new and exciting.

    It takes the username and password fields, and when you click the submit button, it POSTs the result to the server.



    Well, I expected worse. Something like setting the action of the form programatically at page-load time and then umm programatically clicking a 1sq.px  button hidden underneath the real button.

    Sigh, MS seems to be producing more management WTFs more than coding WTFs.



  • Got really used to those, but it's still WTF. Especially this fragment:

    theform.__EVENTTARGET.value = eventTarget.split("$").join(":");

    Why is it separated with '$' in the first place? I understand doing doPostBack as such, because it involves some serverside form-processing magic (actions, etc.). But separating texts with '$' to change it to ':' afterwards is just stupid.

    PS. Is it asp.net's revange, that it tried to place my text in <pre> and not break it? :)



  • @BonzoESC said:

    I don't really know for sure, but it looks like some MS-generated code
    they put in all ASP sites.  Apparently, HTML isn't good enough anymore.


    At least mono does it a bit better:
    var theForm = document.getElementById ('_ctl0');
    function __doPostBack(eventTarget, eventArgument) {
    theForm.__EVENTTARGET.value = eventTarget;
    theForm.__EVENTARGUMENT.value = eventArgument;
    theForm.submit();
    }
    So no document.forms[] weirdness.




  • @BonzoESC said:


    I don't really know for sure, but it looks like some MS-generated code
    they put in all ASP sites.  Apparently, HTML isn't good enough anymore.

    I don't really understand what's the problem here? I admit it could be better but for some reason they decided to do it this way and it look ok to me.

    This script is standart postback event handler and is used by the event handler mechanism of asp.net. So far you're the first I hear complaining about it...


    @BonzoESC said:


    Oh yeah this broken-ass abuse is from http://thedailywtf.com/login.aspx which wouldn't let me log in from one of my browsers.

    Uhh.. and what's your browser? Or you disabled running javascript, flash etc.?



  • @nsimeonov said:

    I don't really understand what's the problem here? I admit it could be better but for some reason they decided to do it this way and it look ok to me.

    This script is standart postback event handler and is used by the event handler mechanism of asp.net. So far you're the first I hear complaining abo

    Uhh.. and what's your browser? Or you disabled running javascript, flash etc.?


    The Rails event handling works just fine with normal HTML, why is ASP.NET broken enough to need the browser to do extra work?

    The browser's not important, it's a failure of MS and/or the authors of this forum software to support browsers that don't have a complicated scripting engine for a task that's perfectly simple without resorting to client-side code.


  • @BonzoESC said:


    The Rails event handling works just fine with normal HTML, why is ASP.NET broken enough to need the browser to do extra work?

    The browser's not important, it's a failure of MS and/or the authors of this forum software to support browsers that don't have a complicated scripting engine for a task that's perfectly simple without resorting to client-side code.

    Yeah, right... flame MS... Do you have a better idea how to trigger server-side events when a field changes or a link is pressed (<a href=...>)? I admit pressing a button could go without javascript but is that your big problem?

    Again what the hell are you using as a browser that can't execute such a simple javascript function.. Lynx, Netscape 4.0 or something even older? And why can't you use for example FireFox? Just curiosity, but what are you using and why ?



  • @nsimeonov said:

    Yeah, right... flame MS... Do you have a better idea how to trigger server-side events when a field changes or a link is pressed (<a href=...>)? I admit pressing a button could go without javascript but is that your big problem?

    Again what the hell are you using as a browser that can't execute such a simple javascript function.. Lynx, Netscape 4.0 or something even older? And why can't you use for example FireFox? Just curiosity, but what are you using and why ?

    I normally like to use a modified version of lynx that works with a text-to-speech program (I am blind), and it's a great inconvenience for me to use a graphical browser that supports javascript, especially when javascript-powered popups happen and make it confusing.

    I won't go as far as to say that microsoft hates blind people, but they aren't very considerate of us much of the time.


  • Please accept my apologies. I thought you're the next linux fan criticising everything about MS. I have had in my past people complaining about virtually everything that doesn't work on their boxes and the people bitching louder were using console browsers or really old browsers because of lazyness - one of them was my friend and was complaining that he had to switch from the server console to his computer to view the site and he didn't want to install newer stuff on the server because it was working stable... you get the picture :)

    For this case especially it could be ommited but as commented out in another thread - MS made the tools for creating applications and if you use the default options for everything you will end up with much bugger WTFs than having a javascript where it could be ommited. However other parts of this website are using javascript and I doubt a non-javascript enabled browser could handle it.



  • how do you read code?  surely it's not text-to-speech.  do you have a brail output like in that old hacker movie.



  • @nsimeonov said:

    I have had in my past people complaining about virtually everything that doesn't work on their boxes and the people bitching louder were using console browsers or really old browsers because of lazyness - one of them was my friend and was complaining that he had to switch from the server console to his computer to view the site and he didn't want to install newer stuff on the server because it was working stable... you get the picture :)



    Now, installing X and a graphical browser on a server would have been a WTF. But web browsing from the server console is already a small WTF anyway...



  • Using js when a simple <input type="submit"/> is enough? WTF?



  • @Reweave said:


    Now, installing X and a graphical browser on a server would have been a WTF. But web browsing from the server console is already a small WTF anyway...

    Ever heard of terminal clients? They're quite popular in some companies - easy to manage, easy to update and you don't need HD in any workstation.



  • @BonzoESC said:

    I found this awesome login form today that does something new and exciting.

    It takes the username and password fields, and when you click the submit button, it POSTs the result to the server.

    Pretty normal, EXCEPT it uses javascript!
    I don't really know for sure, but it looks like some MS-generated code
    they put in all ASP sites.  Apparently, HTML isn't good enough anymore.

    Oh yeah this broken-ass abuse is from http://thedailywtf.com/login.aspx which wouldn't let me log in from one of my browsers.

     

    I... really don't see the fun part - you're being sarcastic, aren't you?

    As someone mentioned, it is indeed standard asp.net postback handling.. the code asigns a value identifying which control has been clicked to generate the submit request - that's why using a standard submit button wouldn't be the same.



  • @nixen said:

    As someone mentioned, it is indeed standard asp.net postback handling.. the code asigns a value identifying which control has been clicked to generate the submit request - that's why using a standard submit button wouldn't be the same.

    I think it's probably a nice reason to force posting the button's id / value / name, along with form, that was submited... Maybe in HTTP/1.2 :)



  • No it wouldn't, but it wouldn't be hard to handle this situation with very minor change in the code, so if are going to talk about about messy html and lazy programmers - this is how it gets. Not too bad but still not perfect. There was a thread about ASP.NET and MS making it easy for programmers to create applications producing crappy html and having pages create enormously large __VIEWSTATE fields. I love asp.net, but I admit that it's quite easy to create pages producing really bad output. As any other tool if you write your program carefully and you aren't too lazy to change a couple of default settings and to pay attention to some details details the results will be really good without any WTFs in it.

    In this case they just put the button and double-clicking it in design time attached the event handler. Really easy to "slap" a login form this way. Just like many other examples, but if we look we can find as many WTFs in programs written in any programming language and of course there are always many ways to avoid them, but we know how it goes when deadlines "ring on the door"...



  • @viraptor said:

    @nixen said:
    As someone mentioned, it is
    indeed standard asp.net postback handling.. the code asigns a value
    identifying which control has been clicked to generate the submit
    request - that's why using a standard submit button wouldn't be the
    same.

    I think it's probably a nice reason to force posting
    the button's id / value / name, along with form, that was submited...
    Maybe in HTTP/1.2 :)




    Are you saying that's not already possible?


    <form method="GET">
    <input type="text" name="the_text" value="a line of text" />
    <input type="submit" name="the_button" value=" the button's label" />
    </form>
    


    When submitted, you'll receive a URI like /foo?the_text=a+line+of+text;the_button=the+button%27s+label


  • @viraptor said:


    I think it's probably a nice reason to force posting the button's id / value / name, along with form, that was submited... Maybe in HTTP/1.2 :)

     

    Sure there is - just too lazy to put a <input type=submit> on the form instead of the asp.net control and double-clicking it to write the event handler.

    This is how an event is triggered from the ASP.NET code and it's good to know how to do it from your own javascript code. However if you want to minimize the HTML output and produce cleaner HTML you may put non-server controls on the form, disable viewstate for controls that don't need it or even the entire page etc, however it requires more thinking and also a bigger budget because stuff like this take time and you know - time is money... But in any case it requires you to stop for a minute and think what the hell you are doing instead of working blindly. I had a guy producing unbelievable stuff because he wasn't lazy and worked overtime instead of stopping for a few minutes to think if there's an easy way. His code was had so many similar functions with minor changes (not cut-n-pasted - it that was the case it would be sort of ok, but it wasn't - he was reinventing the wheel every day) that if he stopped to think for a while he could write one and call it with different parameters and save him a week. I tried to explain it to him without luck - he was listening, agreed that it's better, fixed the code, and next week he produced similar stuff as well...



  • BonzoESC: As people have said, that JavaScript is pretty standard in Microsofts attempts to reduce the "distance" between the client and the server by creating weird postbacks - and thats without involving Atlas - which makes things much much worse!

    But you raise an interesting point. I write for accessibility and find .NET to be quite poor in achieving a truly accessible but highly-specified site without relying on bits of JavaScript and poor markup that MS inject into your code. They claim that ASP.NET 2.0 provides higher accessibility, it does, but I'm afraid developers will think it comes for free.

    So, in response to someone saying "take a bit longer to think about it", we should all do that - to achieve accessibility at the very least.

    What was the text to speech program you use? I'd be interested in trialling it for my sites.

     



  • @nsimeonov said:

    Sure there is - just too lazy to put a <input type=submit> on the form instead of the asp.net control and double-clicking it to write the event handler.


    I'm not sure you understood me. I say, that it would be nice in HTTP (or is it HTML's spec?) if posting a form, would post also __BUTTON=abc, when clicked submit with id='abc'. That would enable any number of buttons in 1 form and doesn't require javascript to handle it.



  • HTML do it.
    If in the same form, you have:
    <input type="submit" value="test1" name="button1" />
    <input type="submit" value="test2" name="button2" />

    If you click on test1, you get button1="test1" in your posted data and no button2 set. And vice versa if you click on test2.



  • @Arkh said:

    HTML do it.
    If in the same form, you have:
    <input type="submit" value="test1" name="button1" />
    <input type="submit" value="test2" name="button2" />

    If you click on test1, you get button1="test1" in your posted data and no button2 set. And vice versa if you click on test2.


    Ok - my bad - I checked it only with value and id. If this one works, then I have to say... WTF?
    Why encode it in some strange string, then translate characters in it, but only after taking it from form in 2 browser-dependant ways (when 1 correct works for all) and post it with JS?
    Why not just 'name' & 'value'? Has anyone got a sane explanation for it?



  • @viraptor said:


    Ok - my bad - I checked it only with value and id. If this one works, then I have to say... WTF?
    Why encode it in some strange string, then translate characters in it, but only after taking it from form in 2 browser-dependant ways (when 1 correct works for all) and post it with JS?
    Why not just 'name' & 'value'? Has anyone got a sane explanation for it?

    Actually yes, there is. It isn't all about buttons. ASP.NET allows you to handle server-side many events. For example change in DropDownList controls (<select>) by triggering a postback event when a different item is selected. Buttons could be handled of course the way you describe although I couldn't find in the w3c spec if they have to be submitted or not, but IE and FF do that so we could assume all browsers will. However being a standart mechanism for triggering server-side events it for all kind of controls and events - this is why this "interesting" script was introduced. Buttons could be an exclusion and could be handled differently I suppose but for some reason they decided to go this way...



  • With ASP.NET any event on any control can potentially cause a postback (roughly speaking).

    All the HTML-only solutions proposed here aren't that flexible.

    I'm not a great fan of it either, but it is quite flexible.  Keep in mind that ASP.NET aims to make web pages more like thick-client applications, not just your father's GET-or-POST-the whole-thing web pages.



  • @nsimeonov said:

    Actually yes, there is. It isn't all about buttons. ASP.NET allows you to handle server-side many events....


    Yeah... I know about other events. AFAIR you could even have onMouseOver or something like this event. But it's not THAT dynamic, that events aren't known at run-time. If there's only but-click - why escape into js?
    If there's more - js is unevitable.



  • @viraptor said:

    If there's only but-click - why escape into js?
    If there's more - js is unevitable.

    Because it's a framework - they unified it in some way. Like anything else that unifies and simplifies some development tasks it sets some boundaries and you have to stick to some specific way ot doing things even if there are better ways to handle a specific situation... However here you can always use the standart html controls and handle form submission the old-fassion way however it's sort of easier to go the other way around and as I pointed before - it required a bit of thinking and some effort to do it.



  • @viraptor said:

    If there's only but-click - why escape into js?


    So the code isn't content-dependent?



  • @nsimeonov said:

    @BonzoESC said:


    I don't really know for sure, but it looks like some MS-generated code
    they put in all ASP sites.  Apparently, HTML isn't good enough anymore.

    I don't really understand what's the problem here? I admit it could be better but for some reason they decided to do it this way and it look ok to me.

    Yeah, except that it fucking replicates a fucking standard browser function called "The Submit Button". Check it out, it's quite nifty

    @nsimeonov said:


    @BonzoESC said:


    Oh yeah this broken-ass abuse is from http://thedailywtf.com/login.aspx which wouldn't let me log in from one of my browsers.

    Uhh.. and what's your browser? Or you disabled running javascript, flash etc.?

    Flash is disabled by default and has to be enabled manually, javascript defaults to blocked and Java applets have been banned alltogether indeed.

    And I use windows...

    @nixen said:

    @BonzoESC said:

    I found this awesome login form today that does something new and exciting.

    It takes the username and password fields, and when you click the submit button, it POSTs the result to the server.

    Pretty normal, EXCEPT it uses javascript!
    I don't really know for sure, but it looks like some MS-generated code
    they put in all ASP sites.  Apparently, HTML isn't good enough anymore.

    Oh yeah this broken-ass abuse is from http://thedailywtf.com/login.aspx which wouldn't let me log in from one of my browsers.

     

    I... really don't see the fun part - you're being sarcastic, aren't you?

    As someone mentioned, it is indeed standard asp.net postback handling..

    Doesn't make it any less stupid.

    @nixen said:
    the code asigns a value identifying which control has been clicked to generate the submit request - that's why using a standard submit button wouldn't be the same.

    Yes it would, most browsers send the data associated with the submit button clicked and that one only...

    Oh wait, IE doesn't, let's force every single browser to go through retarded javascript hacks instead of... I don't know... fixing IE, or only hack for IE, or something... Makes perfect sense !

    BTW they only need to do this because ASP.net defaults to wrapping your whole fucking page in a gigantic form.

    Which is a WTF by itself.

    @viraptor said:
    @nsimeonov said:

    Sure there is - just too lazy to put a <input type=submit> on the form instead of the asp.net control and double-clicking it to write the event handler.


    I'm not sure you understood me. I say, that it would be nice in HTTP (or is it HTML's spec?) if posting a form, would post also __BUTTON=abc, when clicked submit with id='abc'. That would enable any number of buttons in 1 form and doesn't require javascript to handle it.

    It does already... except that IE doesn't handle it.

    @Arkh said:
    HTML do it.
    If in the same form, you have:
    <input type="submit" value="test1" name="button1" />
    <input type="submit" value="test2" name="button2" />

    If you click on test1, you get button1="test1" in your posted data and no button2 set. And vice versa if you click on test2.

    Doesn't work in IE \o/

    @woodle said:
    With ASP.NET any event on any control can potentially cause a postback (roughly speaking).

    All the HTML-only solutions proposed here aren't that flexible.

    So what? How about having an HTML page that actually works and then adding the JS on top of it?

    I mean I don't really care if ASP dumps dog poo in my browser, but it doesn't have to dump only dog poo.

    @woodle said:
    Keep in mind that ASP.NET aims to make web pages more like thick-client applications, not just your father's GET-or-POST-the whole-thing web pages.

    Uuh yeah ok, right.

    That was actually a pretty good joke.



  • It is scary how many people are posting their opinions of ASP.NET and/or this particular function when they have no clue how it works.  Why not actually do some research and make an effort to understand something before you criticize it?  Doesn't that make a little bit of sense?

    It is funny how people are assuming that all ASP.NET forms are submitted via this javascript code just because this function exists ....



  • @Jeff S said:

    It is scary how many people are posting their opinions of ASP.NET and/or this particular function when they have no clue how it works.  Why not actually do some research and make an effort to understand something before you criticize it?  Doesn't that make a little bit of sense?

    It is funny how people are assuming that all ASP.NET forms are submitted via this javascript code just because this function exists ....

    Not really - I criticize it for adding that script, because I tried using single asp:button with single onClick. That can be counted by server. That can be optimalized to <form action=...> and <input type="submit">. No JS. Simple as hell:
    if(no_of_buttons==1 && has_only_click_action(buttons[0])) { don't do JS; }
    Capiche? (I know it's a trolling oversimplification, but why do asp.net people insist, that this situation is normal?)
    Login form is one example. Really - how many times do you need 2 different buttons on a typical form? How many times do you need action other than click?
    If you need that - that should be a special case - and may need JS. I know, that you can do it in simple html and use request object to get all the info. But most people just don't do it.



  • @viraptor said:


    If you need that - that should be a special case - and may need JS. I know, that you can do it in simple html and use request object to get all the info. But most people just don't do it.

     

    Even then using a <input type="submit" name="whatever" value="something"> would add "whatever=something" to the POST request. Perhaps some older browsers wouldn't but .net is generating different scripts depending on the browser anyway.

    Eventhough it's the first time someone complains about that, but I think this complaint was meaningful. Also another thing that irritates me is that I cannot have multiple server-side forms and this javascript it the reason why. And having just one form on the page leads to another set of WTFs like what we have on this forum - handling the enter key separately for different sets of controls - go ahead - check the source... And again we're talking about stupid and/or lazy programmers who don't really understand what's going on when they write some high level code...



  • @viraptor said:

    @Jeff S said:
    It is scary how many people are posting their opinions of ASP.NET and/or this particular function when they have no clue how it works.  Why not actually do some research and make an effort to understand something before you criticize it?  Doesn't that make a little bit of sense?

    It is funny how people are assuming that all ASP.NET forms are submitted via this javascript code just because this function exists ....

    Not really - I criticize it for adding that script, because I tried using single asp:button with single onClick. That can be counted by server. That can be optimalized to <form action=...> and <input type="submit">. No JS. Simple as hell:
    if(no_of_buttons==1 && has_only_click_action(buttons[0])) { don't do JS; }
    Capiche? (I know it's a trolling oversimplification, but why do asp.net people insist, that this situation is normal?)



    You're wrong.  Create a blank ASP.NET form.  Add a single ASP:Button and a single ASP:Label.  On the OnClick event of the button, set the label to some text.  Run it.  Look at the HTML generated. No JS is used.  That function isn't even included in the output.  A standard SUBMIT is used.  Capiche ?

    That function is only added and/or used when a standard submit won't work; i.e., on a client-side event such as OnChanged, or if you want the form to postback when a hyperlink is clicked (i.e., an ASP:LinkButton control).  I am not sure what happens if you don't use the correct server controls; i.e., if you forgo ASP:Button and instead use a regular HTML Button control and attached a server-side event-- that might still use js.  And, of course, what do you expect -- you are not using the proper controls for the framework you are programming in, so non-optimal code might result.

    Add an ASP:ImageButton control and the same thing -- a regular post is used. 

    (note: this is asp.net 1.1, I assume 2.0 works the same way but I don't have it installed on my pc at work).



  • @nsimeonov said:

    @viraptor said:


    If you need that - that should be a special case - and may need JS. I know, that you can do it in simple html and use request object to get all the info. But most people just don't do it.

     

    Even then using a <input type="submit" name="whatever" value="something"> would add "whatever=something" to the POST request. Perhaps some older browsers wouldn't but .net is generating different scripts depending on the browser anyway.

    Eventhough it's the first time someone complains about that, but I think this complaint was meaningful. Also another thing that irritates me is that I cannot have multiple server-side forms and this javascript it the reason why. And having just one form on the page leads to another set of WTFs like what we have on this forum - handling the enter key separately for different sets of controls - go ahead - check the source... And again we're talking about stupid and/or lazy programmers who don't really understand what's going on when they write some high level code...



    That is completely, 100% not understanding a single thing about how ASP.NET works.  It is all on 1 form because the page is stateless and the entire page is re-created on a postback.  Thus,  all of the page's info must be submitted.  If you have two forms, and only 1 form is submitted, how can the server know what is on the other form and how can it re-create it if needed?   That statement about "this javascript being the reason why you cannto have multiple forms" is one of the most ignorant and uniformed things I've ever read here at this site -- and that is really saying something, so congrats!

    ASP.NET is not perfect, but the whole design is based on the concept of a stateless page and having the server do the processing instead of the client.  Again, not perfect, but it works, especially if you know how to use it correctly and how to do things like mimize viewstate and things like that.  You can argue that for your needs an entire page postback isn't what you want, and that's fine, there's ajax and all that, but if you don't use ajax and want your server to do the work to maximize browser compatability and to make good use of true OO programming and all that, then it is an excellent framework to use.   But please make sure that you *understand* how to use the framework and what is was designed for and why it is designed that way before criticizing it.  that's all I ask. 


  • @Jeff S said:



    That is completely, 100% not understanding a single thing about how ASP.NET works.  It is all on 1 form because the page is stateless and the entire page is re-created on a postback.  Thus,  all of the page's info must be submitted.  If you have two forms, and only 1 form is submitted, how can the server know what is on the other form and how can it re-create it if needed?   That statement about "this javascript being the reason why you cannto have multiple forms" is one of the most ignorant and uniformed things I've ever read here at this site -- and that is really saying something, so congrats!



    That's true and in no way specific to ASP.net. Every other way to make a web application faces the same problem as well - either do a lot on the client-side using Javascript or post back the entire f*cking page. It's in the nature of HTML.



  • @Jeff S said:

    @nsimeonov said:

    @viraptor said:


    If you need that - that should be a special case - and may need JS. I know, that you can do it in simple html and use request object to get all the info. But most people just don't do it.

     

    Even then using a <input type="submit" name="whatever" value="something"> would add "whatever=something" to the POST request. Perhaps some older browsers wouldn't but .net is generating different scripts depending on the browser anyway.

    Eventhough it's the first time someone complains about that, but I think this complaint was meaningful. Also another thing that irritates me is that I cannot have multiple server-side forms and this javascript it the reason why. And having just one form on the page leads to another set of WTFs like what we have on this forum - handling the enter key separately for different sets of controls - go ahead - check the source... And again we're talking about stupid and/or lazy programmers who don't really understand what's going on when they write some high level code...



    That is completely, 100% not understanding a single thing about how ASP.NET works.  It is all on 1 form because the page is stateless and the entire page is re-created on a postback.  Thus,  all of the page's info must be submitted.  If you have two forms, and only 1 form is submitted, how can the server know what is on the other form and how can it re-create it if needed?

    Why would it need to recreate it? It doesn't. It only could recreate it, because it's nicer, by using some javascript on top of good ol' HTML.

    In the current state of the things, if you don't have javascript for whatever reason you just can't use most websites using ASP.Net. I'm not talking reduced usability here, I'm talking complete inability to use forms in 90% of the ASP.Net websites, the other 10% being the guys who know their platform and remove things like the client-side viewstate and stuff.

    if you don't use ajax and want your server to do the work to maximize browser compatability and to make good use of true OO programming and all that, then it is an excellent framework to use

    I beg to disagree, ASP.Net browser compatibility is limited to javascript-enabled browsers.

    Launch NoScript or disable JS and most ASP.Net websites can't be used anymore, CommunityServer 1.0 Style.



  • @masklinn said:

    Why would it need to recreate it? It doesn't. It only could recreate it, because it's nicer, by using some javascript on top of good ol' HTML.

    In the current state of the things, if you don't have javascript for whatever reason you just can't use most websites using ASP.Net. I'm not talking reduced usability here, I'm talking complete inability to use forms in 90% of the ASP.Net websites, the other 10% being the guys who know their platform and remove things like the client-side viewstate and stuff.

    if you don't use ajax and want your server to do the work to maximize browser compatability and to make good use of true OO programming and all that, then it is an excellent framework to use

    I beg to disagree, ASP.Net browser compatibility is limited to javascript-enabled browsers.

    Launch NoScript or disable JS and most ASP.Net websites can't be used anymore, CommunityServer 1.0 Style.



    The javascript compatability required to due ajax-style processing on the client is far more than what ASP.NET requires.  The amount of client-side processing (done in javascript by the browser, of course) required by ASP.NET is minimal -- just post the form. That's it.  that 4-line "WTF" code that everyone laughs at is pretty much all that is required by ASP.NET to create a full-featured site.  Other frameworks require much more from the browser, I am sure that you know this so I won't get into details about xmlhttp or hidden IFRAMES and manipulating the DOM and all that which is required by AJAX.  Again, it is perfect or ideal in all situations?  No.  Sometimes the postback model is not great and ajax is often slicker and faster.  But does it work and does it require only minimal JS support?  Absolutely.  And does it allow for full OO programming with full access to all the .net framework features for pretty much all of the code, which all executed on the server?  Absolutely.  If you cannot understand that benefit, then I suppose there is nothing I can write that will convince you.

    I'd like to highlight this line from your post:

    >> the other 10% being the guys who know their platform and remove things like the client-side viewstate and stuff.

    "remove things like client-side viewstate" ??  Huh?   That is something that "guys who know the platform" do?  Maybe *miminize* view state, but if you feel that viewstate is something that should be completely removed, then, again, I can only suggest that you learn ASP.NET before criticizing because your quote strongly implies that you don't have that much experience with it.

    Finally, NO JS is required at all if you limit your site to simple ASP:Button controls and simple form posting -- just like in regular HTML.  JS is required if you want hyperlinks and drop-downs and other controls to fire events -- is this really any different from any other framework?   Did you follow the example I gave you about creating an ASPX page that doesn't use any javascript at all, yet it still has features that process a button press and populates a label on the form?

    Overall, if you want the features, you need the javascript, as AmmoQ mentioned.  Just because community server 1.0 is written in ASP.NET and it requires javascript doesn't mean that *all* sites written in ASP.NET require javascript !


  • By the way, Bonzo -- from your original post:  did you look at all of the HTML on the logon page?  The logon button is a hyperlink.  the hyperlink must submit the form to log you in, right?  How can you do this without javascript?

    Do you think that maybe the reason JS is required is that the author of the page choose to use a hyperlink for a log-on button rather than using a standard SUBMIT control?  What do you think would have happened if a button was used instead?  Do we blame ASP.NET for this or do we blame the author for using a hyperlink to submit a form?  What do you think?






  • @ender said:

    Is this funny javascript the reason I can't simply confirm the login with Enter (because it throws me to the search page, not logged in), but have to click the button?

    Quite possibly. IIRC, if you hit Enter in a form, at least some browsers treat it like you clicked the first Submit button in the form - and on this site, every page is just one big form. (Oh, and the Login button is actually a link styled to look like a button, rather than a real button.) There's some JavaScript in the page that's supposed to detect you hitting Enter and Do The Right Thing, but obviously it isn't working for you.



  • @Jeff S said:



    That is completely, 100% not understanding a single thing about how ASP.NET works.  It is all on 1 form because the page is stateless and the entire page is re-created on a postback.  Thus,  all of the page's info must be submitted.  If you have two forms, and only 1 form is submitted, how can the server know what is on the other form and how can it re-create it if needed?   That statement about "this javascript being the reason why you cannto have multiple forms" is one of the most ignorant and uniformed things I've ever read here at this site -- and that is really saying something, so congrats!

    When the facts speak even Gods are speachless :) I admit I wrote this way too "early" in the morning when I had to be asleep long time ago :)

    My point however was, that it would be nice to be able to put server-side controls outside of the main <form runat=server> or nest forms so you can have control groups and pressing enter would "click" a different button without the need to write tons of javascript code. I know it isn't working this way, just saying it would be nice if it was this way. Or at least if there was a way to create "static" controls that don't have to be in a server-side form.

    Masterpages in ASP.NET 2.0 made the situation better, because you can design the layout on one place only, eliminating the need of web user controls for header and footer (what people used to do in asp.net 1.x) and you may put the login and header html code outside of the main form and if you prefer you could redirect the submit to another page instead of handling it the usual way. Now sure I am explaining it clear enough but I hope you will get the point...



  • @Jeff S said:

    @masklinn said:

    Why would it need to recreate it? It doesn't. It only could recreate it, because it's nicer, by using some javascript on top of good ol' HTML.

    In the current state of the things, if you don't have javascript for whatever reason you just can't use most websites using ASP.Net. I'm not talking reduced usability here, I'm talking complete inability to use forms in 90% of the ASP.Net websites, the other 10% being the guys who know their platform and remove things like the client-side viewstate and stuff.

    if you don't use ajax and want your server to do the work to maximize browser compatability and to make good use of true OO programming and all that, then it is an excellent framework to use

    I beg to disagree, ASP.Net browser compatibility is limited to javascript-enabled browsers.

    Launch NoScript or disable JS and most ASP.Net websites can't be used anymore, CommunityServer 1.0 Style.



    The javascript compatability required to due ajax-style processing on the client is far more than what ASP.NET requires.  The amount of client-side processing (done in javascript by the browser, of course) required by ASP.NET is minimal -- just post the form. That's it.  that 4-line "WTF" code that everyone laughs at is pretty much all that is required by ASP.NET to create a full-featured site.  Other frameworks require much more from the browser, I am sure that you know this so I won't get into details about xmlhttp or hidden IFRAMES and manipulating the DOM and all that which is required by AJAX.

    "Other frameworks" don't forceyou to use "ajax", or any javascript at all, if you don't want nor don't need to.

    And good frameworks implement that little thing called "progressive enhancement" -- you could've heard of "gracious degradation too" which merely means that the websites will work no matter the state of the javascript implementationw

    @Jeff S said:
      Again, it is perfect or ideal in all situations?  No.  Sometimes the postback model is not great

    The postback model universally sucks when it's the only thing you're allowed to use @Jeff S said:

    does it require only minimal JS support?

    That's already far too much.

    @Jeff S said:
    And does it allow for full OO programming with full access to all the .net framework features for pretty much all of the code, which all executed on the server?  Absolutely.

    So what? You can get all that without putting that kind of crap in my browser thank you very much @Jeff S said:

    I suppose there is nothing I can write that will convince you.

    Pretty safe supposition

    @Jeff S said:
    I'd like to highlight this line from your post:

    >> the other 10% being the guys who know their platform and remove things like the client-side viewstate and stuff.

    "remove things like client-side viewstate" ??  Huh?   That is something that "guys who know the platform" do?  Maybe *miminize* view state, but if you feel that viewstate is something that should be completely removed, then, again, I can only suggest that you learn ASP.NET before criticizing because your quote strongly implies that you don't have that much experience with it.

    And I suggest you take Reading Comprehension 101. I never said that you should remove viewstate, I said that you were supposed to remove client-side view state. As in store that frigging viewstate on your server, not on my browser.

    Other than that your analysis of my ASP.Net experience is right, I always tried to steer clear of any ASP I ever saw.

    @Jeff S said:
    JS is required if you want hyperlinks and drop-downs and other controls to fire events -- is this really any different from any other framework?

    Yep, other frameworks don't force javascript down your throat, and often have a javascript-less solution.

    @Jeff S said:
    Just because community server 1.0 is written in ASP.NET and it requires javascript doesn't mean that *all* sites written in ASP.NET require javascript !
    Come on, you told me yourself several times that if you do anything beyond extremely simple stuff you're doomed and you have to have JS. @Jeff S said:
    By the way, Bonzo -- from your original post:  did you look at *all* of the HTML on the logon page?  The logon button is a *hyperlink*.  the hyperlink must submit the form to log you in, right?  How can you do this without javascript?

    You don't, you put a button

    And if you absolutely need that frigging link (me wonders why...) then you hide the submit button at runtime using Javascript and dynamically create a link that emulates it.

    That way the form will still have a submit button, will still work as it should, and you'll be able to do whatever horror you want to that poor submit button.

    @Jeff S said:
    Do you think that maybe the reason JS is required is that the author of the page choose to use a hyperlink for a log-on button rather than using a standard SUBMIT control?  What do you think would have happened if a button was used instead?  Do we blame ASP.NET for this or do we blame the author for using a hyperlink to submit a form?  What do you think?

    I think we should blame the developer for being an idiot, and ASP.Net for helping the creation of such idiocity.



  • @masklinn said:

    Yep, other frameworks don't force javascript down your throat, and often have a javascript-less solution

    Calm down, dude... relax, take a deep breath... now let's be objective, ok? I figured out you don't like ASP.NET and you really love blaming MS when you see something "stupid" created using their tools and frameworks. But why do you think it is MS' fault that someone misdesigned an application? Years ago I saw a java servlet generate 5mb page for 3 calenders generating <td bgcolor="..."><p><font color=...><font name=...><strong><a href="some_javascript">1</a></strong></font></font></p></td> And the javascript was sort of long. They didn't even bother creating a function. So is it SUN's fault for letting people write programs like this? What you say is similar to blaming all the car companies that their cars are way too fast and they have to make sure all cars they produce can't speed up more than 50mph.

    And take into account you can always use HTML controls (e.g. <input type="text" runat="server">) so you can address them almost the same way as ASP.NET web controls but you will have complete control over the situation. Also you can program the same way as in PHP or what I call spaghetty code - all in one - mixed client HTML and server-side code.

    Back to the example: how on earth would you implement without using a javascript the following: you have a dropdown list - <select>...</select> when the user picks one of the elements you have to display a second drop down list pulling the values from the database (first one could be car makes like BMW, Mercedes, Volvo, Mazda, Nissan etc. and second one the models for the selected make). So is there a possible solution? I doubt. Why then flame ASP.NET for writing a javascript for you when you request to do something that's impossible to do without javascript?

     

    @masklinn said:

    You don't, you put a button

    And if you absolutely need that frigging link (me wonders why...) then you hide the submit button at runtime using Javascript and dynamically create a link that emulates it.

    That way the form will still have a submit button, will still work as it should, and you'll be able to do whatever horror you want to that poor submit button.

    This is what you should do in asp.net as well. This would be a GOOD design, however can you count how many times you saw really good design vs something slapped together quickly?

     

    @masklinn said:

    I think we should blame the developer for being an idiot, and ASP.Net for helping the creation of such idiocity.

    The developer only. As any other tool it isn't the fault in the hammer if you hit your finger, it's the idiot holding the hammer...



  • In programming, like any other profession, there are roughly 3 kinds of people:


    1. Those that embrace every tool they use blindy and refuse to accept that others might be better


    2. Those that complain about whatever tool they are using and blame
      anything that they do poorly on the tool being used --it's never their
      fault.


    3. Those that take the time to really learn whatever tool they are
      given, recognize and embrace both its shortcomings and strengths, and
      do the best job they possibly can using that tool without making excuses


      I'll leave it at that.


  • @nsimeonov said:

    @masklinn said:

    Yep, other frameworks don't force javascript down your throat, and often have a javascript-less solution

    you really love blaming MS when you see something "stupid" created using their tools and frameworks.

    You figured wrong on that one, but can't blame you for it.

    @nsimeonov said:

    And the javascript was sort of long. They didn't even bother creating a function. So is it SUN's fault for letting people write programs like this?

    Except that I don't think I've seen many Java frameworks auto-generate javascript years ago. From my memory it was mostly (badly) hand-written, but solely because of the developer.

    @nsimeonov said:

    What you say is similar to blaming all the car companies that their cars are way too fast and they have to make sure all cars they produce can't speed up more than 50mph.

    Nope, what I say is similar to blaming a car company for putting rocket boosters on their cars. I'd have nothing against ASP.Net if it allowed a sane use of JS, I do hate it for creating mostly useless and annoying javascript while barely telling you about it.

    @nsimeonov said:

    And take into account you can always use HTML controls (e.g. <input type="text" runat="server">) so you can address them almost the same way as ASP.NET web controls but you will have complete control over the situation. Also you can program the same way as in PHP or what I call spaghetty code - all in one - mixed client HTML and server-side code.

    You're aware that ASP.Net and PHP (and Java servlets since you talked about them) aren't the only 2 web development platforms in the world aren't you?

    @nsimeonov said:

    Back to the example: how on earth would you implement without using a javascript the following: you have a dropdown list - <select>...</select> when the user picks one of the elements you have to display a second drop down list pulling the values from the database (first one could be car makes like BMW, Mercedes, Volvo, Mazda, Nissan etc. and second one the models for the selected make).

    I wouldn't. First I'd try to extract the true requirements (number of makers and models per maker in the application), then I'd create a fully workable pure HTML application, in this case either using a huge select with OPTGROUPs for each maker (if there aren't too many makers & models) or using a supplementary page to pick the model after you've chosen the maker. Thus having my solution work without javascript

    Then when that part'd be working, I'd add some javascript on the initial page to hook into the models-listing page, I'd generate the dynamic models list and I'd override the form so that it doesn't go through the intermediate page.

    This way, I'd get both a fully working application flow whatever browser is used (including text browsers), but a nicer workflow for people using recent (or javascript-enabled) browsers.

    @nsimeonov said:

    So is there a possible solution? I doubt.

    There always is.



  • @masklinn said:

    Except that I don't think I've seen many Java frameworks auto-generate javascript years ago. From my memory it was mostly (badly) hand-written, but solely because of the developer.

    So the morale of the story is to drop all the visual tools and start generating the HTML using server-side code (echo ..... in PHP or Response.Write(...) in ASP.NET)... this would be a good language because the output would be ONLY what you decide and nothing more.

    Man, as any other RAD tool it adds some code to the output, if everyone using it spends a bit time to read the f****ng documentation to figure out when and what is being added extra to the resulting html code, then we would't encounter WTFs like this, agreed?

    @masklinn said:

    Nope, what I say is similar to blaming a car company for putting rocket boosters on their cars.

    AFAIK the speed limit is 50mph in the cities, so cars shouldn't drive faster than that... and if you get a ticket, it's you driving faster, not the car being able to go beyond 50mph. Same with asp.net - it generates JS code if you request it... so don't do this sort of stuff and you're cool.

    @masklinn said:

    I'd have nothing against ASP.Net if it allowed a sane use of JS, I do hate it for creating mostly useless and annoying javascript while barely telling you about it.

    RTFM



  • Masklin, this got quite an interesting debate about asp.net and web development although there's a a bit passion on both sides :)



  • (all quotes are from masklinn)

    >>And good frameworks implement that little thing called "progressive enhancement" -- you could've heard of "gracious degradation too" which merely means that the websites will work no matter the state of the javascript implementation

    Which framework lets you add events like onchange or submit forms or raise events with hyperlinks but also degrades nicely requiring no JS ?  can you let me know?  Have a specific example?   None of this has anything to do with the programmer, right?  It's all ASP.NET's fault ! 

    >>The postback model universally sucks when it's the only thing you're allowed to use

    It's the only thing you're allowed to use in ASP.NET ?  Wrong again. Why does it "suck"?  Can you explain?   Because it lets the browser store some state w/o using cookies or javascript?  That "sucks"?  Can you explain why? Why is it the only thing you are alllowed to use?

    >>So what? You can get all that (OOP, writing a full-featured app, form validation, etc) without putting that kind of crap in my browser thank you very much

    Again, not if you want to handle client-side events.  How many times do we need to go over this before you can understand?  How many times do I have to ask you to try the very simple excercise I gave several posts back regarding creating an ASP.NET page and adding some controls so that you can see for yourself that no javascript is added unless you use a feature that makes it required in HTML?   Why do you refuse you make yourself a better programmer by actually learning this stuff?  Don't be ignorant.

    >>And I suggest you take Reading Comprehension 101. I never said that you should remove viewstate, I said that you were supposed to remove client-side view state. As in store that frigging viewstate on your server, not on my browser.

    What exactly is wrong with storing view state on the browser?  Can you explain?  Why is it unversally always better to store a page's state on the web server?  Or, if you are not saying that, what are you saying?  ViewState doesn't work? You don't like it?  You don't understand it?  You aren't sure when and where to use?  I suspect the latter since all you can do over and over is say how it "sucks".  Very intelligent analysis.  Are there any drawbacks to storing state's on a web server that you can think of? 

    >>Other than that your analysis of my ASP.Net experience is right, I always tried to steer clear of any ASP I ever saw.

    And yet, you feel compelled to waste our time debating on a topic that again you have demonstrated you know very little about.   Why do people do this?  Notice the debates I get into here at the DailyWTF -- ASP.NET, C#, VB, SQL Server -- that's about it.  I don't try to debate the things I only know the basics of like JAVA or PHP because I am not qualified and I would just sound like an ignorant idiot.  It would be really great if others could do the same, we'd have much better debates and much more intelligent discussions that might actually end up with people learning something.  Instead, it's just trolls writing juvenille things like "VB sucks!" or "ViewState sucks!", leading naive people like me to think maybe they have some knowledge to share so I ask them to explain hoping to learn something from their point of view, but in fact it is just more of the same mindless ranting about things they know nothing about. 

    >>Yep, other frameworks don't force javascript down your throat, and often have a javascript-less solution.

    Again, for the millionth time, neither does ASP.NET.  If you want to handle events like onclick or onchange then you need JS. This is a limitation of HTML.  Do you understand this?  ASP.NET does not "force" any JS down your throat.  Why are you obsessed with this?  That is what determines to you that a particular framework sucks? That some features require javascript if you decide to use them?  Wow. 

    >>You don't, you put a button
    >>And if you absolutely need that frigging link (me wonders why...) then you hide the submit button at runtime using Javascript and dynamically create a link that emulates it.
    >>That way the form will still have a submit button, will still work as it should, and you'll be able to do whatever horror you want to that poor submit button.

    That's great, thanks for the tip.  Why don't we get back to discussing ASP.NET because what you wrote nothing to do with it.  ASP.NET doesn't stop you from doing the exact same thing.  You really should try using it sometime, but I understand why you are reluctant to really learn it -- you might like it and that would really ruin your "hacker cred", huh?
     



  • By the way -- what's even funnier about your position regarding asp.net and all this javascript nonsense is this:

    If you want your app to be non-JS compatable all the way through, how can you accomplish this is ASP.NET?  Just derive from DropDownList, TextBox and other controls and implement your own method of handling the rendering when an onchange event is desired.  Then just use your controls throughout your app -- done!  Your controls can maybe detect the broswer type and output a SUBMIT button labelled "UPDATE" next to the control to simulate this -- w/o javascript of course.  Or you could override a LinkButton control to create a Button for non-JS browsers.  Or create your own cusom controls for these functions that renders the HTML necessary to work.  It is ridiculously easy to do and very flexible and you can immediately change your whole application just by doing some simple inheritance and creating some simple, basic controls that you can use over and over.  What a shitty framework huh? 

    Of course, there is a catch: you have to actually take the time to *learn* ASP.NET in order to implement these features.  Simply following a few "Hello World" examples and then making broad misinformed claims like "ASP.NET doesn't work without javascript!" doesn't cut it.

     


Log in to reply