• (unregistered)

    Also he didn't properly guard his mysql_query. Any fule kno you want to do mysql_query() or die(mysql_error()), or you might wind up with all kind of a headache.

  • (unregistered) in reply to

    Moin,

    :
    What's that giant nasty base64'd glob at the top of the source there for? I mean, while we're on the topic of the forum software.

    My guess is that it's part of what the creators of the software call "Designed from the ground-up for scalable web farm scenarios". As you may or may not have noticed switching between pages of posts is not simply calling a different URI, that would have been far too easy! No, instead it involves JavaScript and POSTing a form to the server (WTF?), and well...you must keep track of this state somewhere. And of course in "scalable web farm scenarios" you can't just put the information into a session and save it on the server.

    The base64 blob contains something which looks like serialized data of some sort, and understanding that is beyond me. Nice to notice however: at the end there are 20 bytes of random garbage, which might very well be a HMAC based on SHA-1. A poor man's digital signature.

    --
    Henryk Plötz
    Grüße aus Berlin

  • (unregistered) in reply to

    Are you guys referring to the ViewState data? Thats used in ASP.NET to save data per session between requests. As you can see, the more you put in there, the larger it becomes, which for web standards, is a bad thing.

    These are aspx pages, so there is code behind to interact with the ViewState data (In theory! :P)

  • (unregistered) in reply to
    :

    If I may list some of the WTFs that are less obvious than the table mêlée:
    * <img ... /> and <link ... /> are _wrong_ in HTML.

    Welcome to the brave new world of XHTML, where every element must be closed. Elements that don't have a close tag need a / at the end of the tag itself.

    Of course, mixing HTML and XHTML and CSS and inline formatting confuses the issue a bit.

  • (unregistered)

    You mean that thing is a session store?

    I'm stickin' to PHP. Free, easy, and not-stupid.

  • (unregistered) in reply to

    Moin,

    :
    Welcome to the brave new world of XHTML, where every element must be closed. Elements that don't have a close tag need a / at the end of the tag itself.

    I know, it's part of my daily routine. But this page is not in XHTML and does not even remotely look like XHTML. If it were supposed to be XHTML the missing "" would for example be real errors forcing the XML parser to stop, instead of minor flaws which any HTML parser can handle. And similarly you can't put the contents of script elements inside comments as the XML parser may throw these away.

    --
    Henryk Plötz
    Grüße aus Berlin

  • (unregistered)

    trigger_error(E_ANAL);

  • (cs) in reply to

    Re: " You mean that thing is a session store?"

    No, it isn't the session data - that is stored on the server side, either on a single server or to a DB depending on your configuration.

    It is used to store information about controls.  For example, the first time you render the page, say you have a dynamic listbox.  Rather than rebuild that dynamic listbox every page load (during postbacks), it stores the contents and attributes for that control in the ViewState data.  For a better explanation than I care to take the time to write (and why reinvent the wheel?), check out http://www.dotnetjohn.com/articles/articleid71.aspx

    Also , most people use GZIP compression on their pages to reduce the viewstate payload.  You can also directly gzip the viewstate data itself, and un-gzip it when postback occurs by overrriding the viewstate handlers in your page code.  We gzip all our page output, and on a few pages that have huge viewstates, I also gzip the viewstate data.





  • (unregistered) in reply to
    :

    Moin,

    [image]  wrote:
    Welcome to the brave new world of XHTML, where every element must be closed. Elements that don't have a close tag need a / at the end of the tag itself.

    I know, it's part of my daily routine. But this page is not in XHTML and does not even remotely look like XHTML. If it were supposed to be XHTML the missing "" would for example be real errors forcing the XML parser to stop, instead of minor flaws which any HTML parser can handle. And similarly you can't put the contents of script elements inside comments as the XML parser may throw these away.

    --
    Henryk Plötz
    Grüße aus Berlin

  • (unregistered) in reply to

    Great, it ate my post.

    What I was trying to say is: those errors would stop parsing in XML, or XHTML sent as application/xhtml+xml, not in other cases.

  • (unregistered) in reply to Drak
    Drak:
    Perhaps if you include it in every page it saves you from thinking or something?


    I find it more likely that if you include this in every page it prevents you from thinking.
  • (cs) in reply to
    :
    [image]  wrote:

    <FONT style="BACKGROUND-COLOR: rgb(239,239,239)">Yes, an "em" is related to the height of the letter "m" in the current font at the current size, which is certainly not the same as a size of 100%. It's probably more like saying "font-size: 50%" which is usually going to be too small.</FONT>



    No, that is wrong.

    The unit "em" is not related to the letter "m" in CSS.  It is the height of the font, so 1 is the normal size and 2 is twice as big. Click here for the CSS standard.  The tricky thing is that "em" when applied to the font-size property refers to the size of the font in the parent element.  That means if you have 0.5em nested twice, you actually get 0.25 the size of the parent font.

    The "em" used to be the size of the letter M, but in modern times that is no longer the case.  Not all fonts even have the letter M.  (Chinese language fonts for example.)

    Don't mix "definition" with "implementation". A typographic em is the width of the upper-case glyph "M" in the current font. CSS doesn't change the definition of an em -- or an ex, which is defined as the height of the lower-case glyph "x" -- but most user-agents handle both incorrectly, making an ex half of the pixel height and an em the full height. The problem is font metrics -- given the same font size, Times New Roman should have a significantly bigger ex than, say, Garamond, and significantly smaller than Century School. Browsers simply don't take the time to read the metrics in the font definition files. Don't think of that as a permanent situation, though -- look for high-definition screens (200+ pixels per inch) to make real use of font metrics in the next few years.

  • (cs)

    <font face="Verdana">Re: pre{font-size:1em}

    On the </font><font face="Verdana">body element, yes, you'd have a WTF.  However, MSIE, Mozilla/FF, and Opera (the "big three" browsers these days, as far as my employer and I are concerned) all have slightly different default rules regarding the pre element.  I forget which is which offhand, but one of them defaults the pre element to 8pt, one to 0.6em, and one to 1.0 em (related to the parent element.)

    Remember that the Cascade puts the C in CSS.  The user-agent style sheet is first, then the author style sheet, and then the user's style sheet.  If you don't specify the pre font size, the user-agent will, and the vast majority of users don't even realize that they can change that.

    By the way, I forget which is which because I just got in the habit of always specifying the font-size of pre elements (usually 0.8em or 0.9em, since monospace fonts look a bit big and goofy next to sans-serifs.)  Then you never have to worry about it.

    So, if you had this:
    css:
    div {font-size:12pt}

    xhtml:
    <div>
        <pre>this is pre-formaterrific!</pre>
    </div>

    Then you'd have 8pt in one browser, (12*0.6=) 7.2pt in another (which ends up being 7pt, except for every fifth letter that skips forward an extra pixel - noticeable once you know what to look for, and ugly, imo), and 12pt in the third.  It's a mess.

    Best to just spend the infinitesimal fraction of a second, and tell the user agent to show the proper font-size.


    As for the PHP, I was going to show how to do it in much fewer lines with PHP's wonderously beautiful dereferencing magic ($$var = $_{$var}, etc) but someone else beat me to it.  Nicely done.
    </font>

  • (cs)

    In Programming Perls, Bentley gives an example much like the second part of this in which a programmer had 50-odd separate variables named c1 through c50 (in the second edition, he upped the example to 500 variables), and then painstaking checked the value of another variable 50 (or 500) times to see which of the numbered variables to increment.

    His comment in the first edition was, "managers who pay by the line may feel free to faint now." He goes on to mention that he has seen hundreds of programs which did this; in the first edition he says that is used to be particularly common in COBOL, where tables (arrays, not tables in the DBMS sense) are usually considered fixed structures.

  • (cs) in reply to

    Did "Data" from Star Trek write this code?

  • Scrub (unregistered) in reply to utoxin
    utoxin:
    .... Wow. Another post that just... defies description. That code is wrong on many many many levels. I could probably optimize it down to 15 lines or less. In fact... Here's my best go.

    (Note: I assume he's already selecting all the columns in the table. If that's not true, just change the query back to how it was.)
    [code language="c#"]
    include "../../../db.inc/db.inc.php";

    $result = mysql_fetch_array(mysql_query("SELECT * FROM gct WHERE casenum = '$aid'"));

    unset($result['casenum']);
    $xcontype = $result['contype'];
    unset($result['contype']);

    foreach ($result as $key => $value) {
    if ($value == 'on') {
    $varname = "_{$key}";
    $$varname = "checked":
    }
    }
    [/code]

    (It won't indent the code. Not sure why...)

    Wouldn't this code break if you add a column to the table? 'Select * ...' is never a good idea in production code

  • Bob (unregistered)

    Doesn't this code belong the the article 'The X-Data Specialist'?
    There i saw the same bunch of awkward columnnames and some (actually many) x-es which may be interpretable (after drinking too much) as 'checked'.


  • (cs)

    This is so bizzare, I just had to sort it out.

    The first portion is odd not only because it' hard coded, but also because it gathers ( what looks to be a grid-in-a-table ) certain consectutive grid rows within the table. Imagine a table with each grid cell as a field in the table.

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a |b |c |d |e |f |g |h |i |j |k |l |m |n |o |p |q |r |s |t |u |v |w |x |y |z |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a1|b1|c1|d1|e1|f1|g1|h1|i1|j1|k1|l1|m1|n1|o1|p1|q1|r1|s1|t1|u1|v1|w1|x1|y1|z1|
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a2|b2|c2|d2|e2|f2|g2|h2|i2|j2|k2|l2|m2|n2|o2|p2|q2|r2|s2|t2|u2|v2|w2|x2|y2|z2|
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a3|b3|c3|d3|e3|f3|g3|h3|i3|j3|k3|l3|m3|n3|o3|p3|q3|r3|s3|t3|u3|v3|w3|x3|y3|z3|
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a4|b4|c4|d4|e4|f4|g4|h4|i4|j4|k4|l4|m4|n4|o4|p4|q4|r4|s4|t4|u4|v4|w4|x4|y4|z4|
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a5|b5|c5|d5|e5|f5|g5|h5|i5|j5|k5|l5|m5|n5|o5|p5|q5|r5|s5|t5|u5|v5|w5|x5|y5|z5|
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a6|b6|c6|d6|e6|f6|g6|h6|i6|j6|k6|l6|m6|n6|o6|p6|q6|r6|s6|t6|u6|v6|w6|x6|y6|z6|
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a7|b7|c7|d7|e7|f7|g7|h7|i7|j7|k7|l7|m7|n7|o7|p7|q7|r7|s7|t7|u7|v7|w7|x7|y7|z7|
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a8|b8|c8|d8|e8|f8|g8|h8|i8|j8|k8|l8|m8|n8|o8|p8|q8|r8|s8|t8|u8|v8|w8|x8|y8|z8|
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |a9|b9|c9|d9|e9|f9|g9|h9|i9|j9|k9|l9|m9|n9|o9|p9|q9|r9|s9|t9|u9|v9|w9|x9|y9|z9|
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    who knows how many more fields there are......
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    ... and who knows why the a1 thru z1 are absent in the query.

    At first glance you would think... just select *.  Sort it out later.
    When in fact the second segment does just that.... the hard way.
     
    Why? because of the call to mysql_fetch_row($result)), which fetches a numerically indexed array, not associative.

    Hence,  the need for the list construct.  the hard way, by manual assignment.
     
    Shoulda used mysql_fetch_array($result)). Then the field names woulda been the array keys, negating the need for the list construct, as well as the need to internalize the "x" version of the key.
     
    The next oddity is that all the fields are probably an ENUM 'on' or 'off'. Perhaps some variety as well... 'almost on', etc. This coulda been done with a simple int field. Certainly would be faster on the PHP side during the value comparison. Better to compare numbers than words.

    Most likely this is to matchup with an <option>on|off</option> html tag.

    Although, as an aside... if the *only* use for the ENUM is to set the "checked" value of the <option> tag,  The ENUM's shoulda been either '' or ' checked'. That woulda eliminated the need for the value comparison altogether.

    That said, that leaves the question... what is this?

    There seems to be 26 options for each numerical variation. Which appears to be aligned with the alphabet.  So why would you need to be able to turn 'on' or 'off' a specific char?  And why not numbers or special chars.

    Is this a filter? Is this a mask? Is this multi-lingual ( hence the variations ), is this a tool for teaching?, a random word generator?

    The WTF is the programming approach, the real curiosity is what is it.

  • (cs) in reply to
    Anonymous:
    :
    Now here's another WTF everyone else seemed to miss:
    <FONT color=#990000>casenum, contype
    FROM gct WHERE casenum = '$aid'"

    </FONT>
    What's the point of grabbing the SAME column from the database as the one that is in the "WHERE" clause?

    The PHP list() function will "Assign variables as if they were an array".

    I FOUND THE PROBLEM WITH THE MINISCULE CODE!!!
    Some idiot that wrote the css stylesheet for this co-called "forum" placed this code in it:
    pre.source
    {
    <FONT color=#ff0000>font-size: 1em;</FONT>
    margin-left: 20px;
    color: black;
    font-family: Lucida Console, Courier New, Courier;
    background-color: gainsboro;
    }

    Maybe this forum should have it's own WTF threads!

    -- Never doubt the knowlege of 14-year-olds! Wink

    I did NOT write the css stylesheet (a redundant tautology in itself) for this forum software and I resent the implication.

  • (cs)

    TRWTF is that there are two columns "j9".

  • ppu-prof_Si (unregistered)

    Наша группа искусных исполнителей завершена предлагать вам новаторские системы утепления, которые не только снабдят надежную охрану от мороза, но и преподнесут вашему жилью оригинальный вид. Мы работаем с современными веществами, ассигнуруя долгий срок эксплуатации и блестящие эффекты. Утепление фасада – это не только сбережение на т&

Leave a comment on “Trust me, It's Easier This Way”

Log In or post as a guest

Replying to comment #:

« Return to Article