• Mike Robinosn (unregistered)

    At least they're not storing it in the database

  • (cs)

    Script, don't go away mad Script, just go away

    Sorry, I couldn't resist.

  • Puzzled (unregistered)

    I don't get it. This piece of javascript is created on the server-side and only rendered whenever that page has that input querystring. So I guess the wtf is client-side code being strung together on the server-side? I hope that really isn't it, cause in this instance it kinda makes sense to me. Sure it could have all been done on the client-side, but meh.

  • SilentRunner (unregistered)

    Remy, would you please explain the code?

    I thinks it's rude to show code that you say is a WTF, but then fail to explain the code.

  • (cs) in reply to Puzzled

    Look carefully at the code. The JavaScript strung together on the server does one and only one thing- it submits the form back to the server.

  • Puzzled (unregistered) in reply to Puzzled
    Puzzled:
    I don't get it. This piece of javascript is created on the server-side and only rendered whenever that page has that input querystring. So I guess the wtf is client-side code being strung together on the server-side? I hope that really isn't it, cause in this instance it kinda makes sense to me. Sure it could have all been done on the client-side, but meh.

    Nvm... actually looked more at the rest of the code. All it took was one more gulp of coffee. That is actually kinda funny. I assumed their search on the client-side just pulled in some results all Ajaxy-like.

  • Vilx- (unregistered) in reply to Puzzled

    Ot could have easily been done all on server side, without needing that piece of Javascript at all (which causes a redundant HTTP request), and in about 2 lines of code.

  • Vilx- (unregistered)

    And all the background-colors go - WTF? There's one too few zeroes in #D0000!

  • fishdude (unregistered)

    TRWTF is using WebForms and not MVC, right?

  • (cs)

    TRWTF is using JavaScript to cornify the word "JavaScript"

  • (cs) in reply to jnewton

    It's meta.

  • benefitofthedoubt (unregistered)

    There seems to be something missing. We can't assume its a bad code by seeing the server code tells the client to post to the server.

    The server code could be looking for other stuff collected by the client, and since the form data is missing, it wouldn't have it.

    We don't know what the search method does/collects. If it requires a query field.

    Also, what about search engines. If a get request hits the server this may cause a problem. This method would prevent a browser that doesn't execute javascript from issuing a post.

  • (cs) in reply to benefitofthedoubt
    benefitofthedoubt:
    There seems to be something missing. We can't assume its a bad code by seeing the server code tells the client to post to the server.

    The server code could be looking for other stuff collected by the client, and since the form data is missing, it wouldn't have it.

    We don't know what the search method does/collects. If it requires a query field.

    Also, what about search engines. If a get request hits the server this may cause a problem. This method would prevent a browser that doesn't execute javascript from issuing a post.

    It's just plain not efficient. Correct me if I'm wrong, as I often am:

    The search query gets sent to the server, which returns this garbage, so that your "search results" consisting of everything that makes the web page gets returned and rendered from the server, and then (we are assuming cause the search code was stripped) that another (ajax?) request gets sent BACK to the server (another request) to actually display the results.

    You get this illusion that the website you are working with is ultra fast, even if your search results take a few seconds to showup, at the expense of efficiency.

    Anyone who has javascript disabled is probably gonna see a "You need javascript enabled" error message long before it gets to this page.

    Also, I hate javascript. It is the hillbilly backwoods language of the internet.

  • (cs)

    Okay, let me see if I understand this: The client registers a startup script that looks to see if the http request contained a search string. If it does, it loads the search text box with that string, then calls search with an empty string, after issuing a click on the search image button, presumably to do the search immediately.

    As opposed to simply sending the search results.

    Efficiency? If I understood it right, not even close.

  • benefitofthedoubt (unregistered) in reply to PiisAWheeL

    the javascript message wouldn't appear unless the author put logic in for that. This possibility that this may prevent search engines from submitting searches is still a possibility, efficient or not.

  • (cs) in reply to benefitofthedoubt
    benefitofthedoubt:
    the javascript message wouldn't appear unless the author put logic in for that. This possibility that this may prevent search engines from submitting searches is still a possibility, efficient or not.
    You are throwing matches on a campfire. Theres plenty wrong before you worry about the clients with javascript turned off.
  • benefitofthedoubt (unregistered) in reply to Coyne

    @Coyne, No, its simply checking if the current request was a post request, containing the expected fields. If not it returns javascript to the client to force an empty post request. Seems ironic since the page already has the users there...why not just serve an empty result set.

  • benefitofthedoubt (unregistered) in reply to PiisAWheeL

    why would you assume that there is another ajax request fired in the search logic? The code was see just shows they check 1 field. The search logic may just look at the rest of the request fields....and its done.

  • (cs)
    OP:
    string script = "\r\n";
Page.ClientScript.RegisterStartupScript(
        typeof(Page),
        "CheckEnterPressed",
        script);

    I'm pretty sure this is complete BS and/or incomplete. The client-side script registered on the server consists only of a Windows-style newline (carriage return, line-feed). The script parameter is JavaScript code, and white space is ignored in JavaScript, so the script should do nothing. It should not submit the form... Either I'm missing something, everybody else is seeing imaginary things, or TDWTF has resorted to trolling its readers...

  • benefitofthedoubt (unregistered) in reply to xtremezone
    xtremezone:
    OP:
    string script = "\r\n";
Page.ClientScript.RegisterStartupScript(
        typeof(Page),
        "CheckEnterPressed",
        script);

    I'm pretty sure this is complete BS and/or incomplete. The client-side script registered on the server consists only of a Windows-style newline (carriage return, line-feed). The script parameter is JavaScript code, and white space is ignored in JavaScript, so the script should do nothing. It should not submit the form... Either I'm missing something, everybody else is seeing imaginary things, or TDWTF has resorted to trolling its readers...

    if you are reading from an RSS feed reader it strips the javascript

  • noname (unregistered)

    There seems to be some code missing in some browsers. Here the full code i hope:

    protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
if (!string.IsNullOrEmpty(Request.QueryString["input"]))
{
SearchTextBox.Text = Request.QueryString["input"].ToString();
string script = "<script language=""Javascript"">\r\n" +
"var searchImageButton = GetControl("SearchImageButton", "INPUT");\r\n" +
"searchImageButton.click();" +
"\r\n</script>\r\n";
Page.ClientScript.RegisterStartupScript(typeof(Page), "CheckEnterPressed", script);
}
Search("");
}
}
    

    protected void SearchImageButton_Click(object sender, ImageClickEventArgs e)
{
Search(SearchTextBox.Text);
}
    

    private void Search(string searchString)
{
… //Do the actual searching
}

  • (cs)

    Thanks. That makes better sense... xD If I view source it all becomes clear. Both in Google Reader and in Firefox the embedded <script> blocks seems to be interpreted as HTML/JavaScript instead of text.

  • fab (unregistered) in reply to benefitofthedoubt

    Thank you! I thought I was too stupid to get the point... also, you cannot see the JS if you have JS disabled (at least from unknown/different domains, what I do) - quite ironic.

    This should be fixed. I had a bit of sloppy copyapasta in there which Chrome didn't choke on, so I didn't notice. --Remy

  • C-Derb (unregistered)

    Seems to me that this is a poorly implemented way to account for bookmarked searches. The script only gets generated when the web form is loaded on the initial request (not on post back).

    So if someone has bookmarked www.initech.com/search?input=wtf, when requested, this code should cause the search to be executed and have the results returned (I assume that is what the Search method does). So that part is reasonable. Poorly implemented, but a reasonable need is addressed.

    The problem is sending a script back to the client, instead of just calling the Search method directly. Also, I have no idea how you would end up with "input" in the query string of the url since the text box is called SearchTextBox.

  • benefitofthedoubt (unregistered) in reply to C-Derb
    C-Derb:
    Seems to me that this is a poorly implemented way to account for bookmarked searches. The script only gets generated when the web form is loaded on the initial request (not on post back).

    So if someone has bookmarked www.initech.com/search?input=wtf, when requested, this code should cause the search to be executed and have the results returned (I assume that is what the Search method does). So that part is reasonable. Poorly implemented, but a reasonable need is addressed.

    The problem is sending a script back to the client, instead of just calling the Search method directly. Also, I have no idea how you would end up with "input" in the query string of the url since the text box is called SearchTextBox.

    interesting idea with the bookmarks, maybe the text box used to be called input, so this is a poor way of handling the old bookmarks

  • Jess (unregistered)

    Don't use scripts to do things that HTML can do perfectly. HTML is going to be simpler, more secure, and more portable.

    Just don't.

    Reaching for your handy-dandy power drill out of sheer habit, when all you need is a pencil, is TRWTF.

    As for you trolls who are thinking a script will protect your server from unwanted search engine traffic: if you're relying on client scripts to secure your server, you need to change jobs now.

  • Not-particularly-pedantic dickweed (unregistered) in reply to jnewton
    jnewton:
    TRWTF is using JavaScript to cornify the word "JavaScript"
    TRWTF is downloading the image every time instead of letting the browser cache the result (just give clients a list of static urls).
  • Maude (unregistered)
    emphasized the use of client-side code to keep the application responsive
    In before people flamewar about how using on javascript is not just wrong, but evil (Darn kids, get off my processor!).
  • myName (unregistered)

    If you post code please say what the WTF is for people who don't read that language.

    Or do you like being smug?

  • wonk (unregistered) in reply to myName
    myName:
    If you post code please say what the WTF is for people who don't read that language.

    Or do you like being smug?

    Why should I tell you if I like being smug?

  • C-Derb (unregistered) in reply to wonk
    wonk:
    myName:
    If you post code please say what the WTF is for people who don't read that language.

    Or do you like being smug?

    Why should I tell you if I like being smug?

    If you don't know why, I'm not going to tell you.

  • Aargle Zymurgy (unregistered) in reply to Vilx-

    Is that Homer Simpson's color? D0H?

  • Anon (unregistered)

    I think I might get the idea of this thing, though I'm not a web developer so may be mistaken. They indeed increase UI experience with it. Look at it this way: suppose searching does take some time on the server. If they did the search in Page_Load the page would take longer to load. Now with this trick, the page is loaded, then Javascript is run which clicks the Search button. Now the search runs but the user already sees the page loaded and thinks things are running smoothly, even if they actually do not (the page is not responsive anyway). Makes sense?

    This is probably a false-positive WTF :)

  • C-Derb (unregistered) in reply to Anon
    Anon:
    I think I might get the idea of this thing, though I'm not a web developer so may be mistaken. They indeed increase UI experience with it. Look at it this way: suppose searching does take some time on the server. If they did the search in Page_Load the page would take longer to load. Now with this trick, the page is loaded, then Javascript is run which clicks the Search button. Now the search runs but the user already sees the page loaded and thinks things are running smoothly, even if they actually do not (the page is not responsive anyway). Makes sense?

    This is probably a false-positive WTF :)

    Your explanation might have some merit if they were using Ajax to request the search results, but it doesn't appear that this code uses Ajax. However, if they are using Ajax, they should just call the Ajax code, don't resubmit the search form with javascript.

    Definitely a WTF.

  • (cs)

    WTF did I see a pink unicorn??? Am I drunk?

  • (cs) in reply to TGV
    TGV:
    WTF did I see a pink unicorn??? Am I drunk?
    According to some posters in the forum the name of the author is Remy Martin.

    This is false, but the effects of reading his articles always appear to be similar...

  • Tom (unregistered) in reply to myName

    I've learned more here playing "Find the WTF" in languages I don't know than I every would have having them spoon-fed to me like I'm an eight year old.

    Do the work yourself. You'll be better for it.

  • Agention (unregistered) in reply to benefitofthedoubt
    benefitofthedoubt:
    xtremezone:
    OP:
    string script = "\r\n";
Page.ClientScript.RegisterStartupScript(
        typeof(Page),
        "CheckEnterPressed",
        script);

    I'm pretty sure this is complete BS and/or incomplete. The client-side script registered on the server consists only of a Windows-style newline (carriage return, line-feed). The script parameter is JavaScript code, and white space is ignored in JavaScript, so the script should do nothing. It should not submit the form... Either I'm missing something, everybody else is seeing imaginary things, or TDWTF has resorted to trolling its readers...

    if you are reading from an RSS feed reader it strips the javascript

    Ha! Now that's a WTF in itself. Because the programmer was probably unaware of how to quote javascript in an RSS feed such that it's not a code injection attack. Morons.

  • Overcharging consultant (unregistered) in reply to fishdude
    fishdude:
    TRWTF is using WebForms and not MVC, right?

    Most of the time the WTF IS using MVC...

    catchpa: minim: the way i like it and a palindrome as a bonus.

  • dogmatic (unregistered)

    Doesn't this just prevent spiders from caching search results? This is the first WTF I don't get.

  • benefitofthedoubt (unregistered) in reply to Jess
    Jess:
    Don't use scripts to do things that HTML can do perfectly. HTML is going to be simpler, more secure, and more portable.

    Just don't.

    Reaching for your handy-dandy power drill out of sheer habit, when all you need is a pencil, is TRWTF.

    As for you trolls who are thinking a script will protect your server from unwanted search engine traffic: if you're relying on client scripts to secure your server, you need to change jobs now.

    your clear misunderstanding and implication that evet using javascript is wrong shows that you need to switch jobs [b]now[b]. html is not in a state to replace javascript

  • (cs)

    Maybe I'm missing something or just rusty on javascript, but it looks like what this does when passed a search string is load the (blank) search page and populates the search bar with the provided string. Then only when the user presses enter or clicks the search image button, it executes the actual search.

    The Page_Load() doesn't directly trigger the SearchImageButton_Click() as others seem to claim. It requires a manual action. The javascript just makes the search the default action when enter is pressed.

    There could be reasons to require manual review of the search string before executing the search; without knowing the requirements it's hard to say if this is a WTF or not.

  • Matthew Herrmann (unregistered)

    The WTF is, why not just parse the query string in the server code to do the search, like a 1994 CGI server? It doesn't break the internet, and its easy. And POST with action=get.

    Its fighting a layer of abstraction instead of just removing it.

  • anonymouse (unregistered) in reply to benefitofthedoubt

    If you do any sort of technical writing, your inability to correctly interpret that comment and form a well-written response indicates that you need to switch jobs [b)now[d]. The comment you quoted does not say HTML can replace Javascript, merely that it can do some of the same things.

  • MrBester (unregistered) in reply to no laughing matter
    no laughing matter:
    TGV:
    WTF did I see a pink unicorn??? Am I drunk?
    According to some posters in the forum the name of the author is Remy Martin.

    This is false, but the effects of reading his articles always appear to be similar...

    Porter is also an alcoholic drink...

  • qbolec (unregistered)

    I once did something similar, and it was because IE did not allow redirects (HTTP Found) from https to http (i.e. after logon) so we had to use <meta refresh> together with window.location = something.

    Also sometimes you do want force the method to be POST, because of some CSRF security issues. Say you have some logic in onsubmit event of the form that adds some token to a hidden field of the form...

    It's not that I understand the code, or the real problem they solved, and clearly I would ask WTF loud seeing that, but then I would try to find the developer and ask him to provide more details and document the code apropriately.

  • Web Dev (unregistered)

    The real WTF is ASP.NET webforms.

  • blank (unregistered) in reply to Cat
    Cat:
    Maybe I'm missing something or just rusty on javascript, but it looks like what this does when passed a search string is load the (blank) search page and populates the search bar with the provided string. Then only when the user presses enter or clicks the search image button, it executes the actual search.

    The Page_Load() doesn't directly trigger the SearchImageButton_Click() as others seem to claim. It requires a manual action. The javascript just makes the search the default action when enter is pressed.

    There could be reasons to require manual review of the search string before executing the search; without knowing the requirements it's hard to say if this is a WTF or not.

    This.

    i dunno at what point the server-side Page_Load() is invoked, but the js sent back seems to be binding a form submit action to the enter key.

    my guess would be that there's a funky ajax autosuggest handler already bound to (other) keypresses in the client-side search box, but Enter isn't set to submit [that] form initially [or rather, when when the search box is empty]

    without more context in the OP it's rather dumb to call this a WTF

  • wallflower (unregistered) in reply to blank
    blank:
    without more context in the OP it's rather dumb to call this a WTF

    Code that is obscure is Worse Than Failure.

  • blank (unregistered) in reply to wallflower
    wallflower:
    blank:
    without more context in the OP it's rather dumb to call this a WTF

    Code that is obscure is Worse Than Failure.

    although i agree with your statement, this code really isn't obscure; any percieved obscurity here is due to lack of context in the OP.

Leave a comment on “Take a Walk on the Client Side”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article