• (nodebb)

    Frist off, I adore the way that $varNamePrefix contains a suffix.

  • (nodebb)

    What about using grpID variable as an index for the user_Arr_PREFIX?

  • (nodebb) in reply to Steve_The_Cynic

    Maybe the dev didn't like the s-word?

    It's a bit odd to have that type of code dynamically generated - are they trying to ruin their cache performance or is it simply over engineered code. Ah, questions, questions :-)

  • Vera (unregistered)

    Yesterday was foreshadowing, today is the payoff.

  • TS (unregistered)

    It's never occurred to me before that one might need syntax colouring to identify which language a particular bit of text is in. You might need to be a mantis shrimp to make sense of it though.

  • Sauron (unregistered)

    No. Just no. Don't do that kind of mix of PHP and JS.

    But here's the scary part: it was remarkably bug free. The developer responsible for this had managed to do this everywhere, and it worked. Reliably. Any other developer who tried to change it ended up causing a cascade of failures that meant weeks of debugging to make what felt like should be minor changes, but in the state which ALicia inherited it, everything worked. Somehow.

    Now that's mysterious. So that dev was an evil genius after all.

    Tbh, generating JS in PHP is not a completely absurd idea, BUT only in the case of a PHP-to-JS transpiler. It doesn't make sense to just generate that JS code on-the-fly like that otherwise.

  • (nodebb)

    Mixing PHP and JavaScript is like mixing solid waste and liquid waste. You need to flush them both down the toilet.

  • ttlanhil (unregistered)

    Sometimes writing from the DB as JS data in the HTML you output is correct. Not how it's done here, of course, but if it's static data that the current request has loaded anyway, it may make sense. But if it's more than a couple of variables (say, you want to populate user's display name, userid, and a CSRF token) then even writing it into the HTML you should probably separate data and code (e.g. if using django, the json_script filter)

  • (nodebb)

    It's not unreasonable to have PHP generate a JS array rather than fetching it with AJAX. But the right way to do this is to build the entire array in PHP, then use

    var js_array = <?= json_encode($php_array) ?>;

    rather than generating lots of assignments.

    This also ensures that special characters are properly escaped.

  • maurizio (unregistered)
    Comment held for moderation.
  • Duke of New York (unregistered)

    When your tool is a template processor, every problem looks like concatenation.

  • Duke of New York (unregistered)

    What was it Dijkstra said about APL: "A mistake carried through to perfection … the language of the future for the techniques of the past." If you fell through a time warp to 2005, when JSONP didn't exist and XHR wasn't portable, you might think this was awfully clever, or or at least cleverly awful.

  • Evil Genius Johnny Holzkopf (unregistered) in reply to Sauron
    Comment held for moderation.
  • mihi (unregistered)

    To be honest, I wrote something similar to this (maybe even nested array) around 1997 (yes, PHP was around there already and you did not have to think about register_globals being on or off since it was just there). While Netscape 3 supported JavaScript and arrays, it did not support array literals. On the other hand it did not support dynamic DOM manipulation either, so everything you could do with such arrays was work with document.layers (to make a flying mouse cursor clock) or use text input fields with border=0 to output stuff. IE3 supported DOM manipulation but no layers. Not sure about array literals. And yes, I used that idiom even some years later, because it just worked.

    When the code in question is equally old, no wonder that it still works. You had to code really carefully in these days (I already mentioned register_globals was on all the time, so every uninitialized variable was a potential security issue), and I have the impression that the resulting code was more solid than typical fast-written code today is.

  • Duke of New York (unregistered)
    Comment held for moderation.
  • (nodebb)

    Whilst looks like a god-awful mess, I can understand the impetus to do it. The really hard bit is writing it with suitable abstractions so that the core logic isn't hard to read.

Leave a comment on “JaphpaScript”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article