• (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)

    It may works, but this code call for all type of XSS, especially because PHP is generating JavaScript, not HTML, so standard escaping functions do not works.

  • 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

    Japha! My evil servant! Now that we have interwoven JS and PHP, we need to add another language! Fetch me... the jars of... ESSS ESSS EEEEHHH!!! S! S! I! SSI will rule! Ahahaha ahahaha! Ha haha, ha haha haha!!!

  • 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.

  • (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.

  • Tyler W. Cox (unregistered)

    To be fair, in the ancient days before AJAX was well standardized and JSON wasn't a thing, I was guilty of this myself while transitioning from server rendered pages to client side processing. So this could be from a codebase taped in amber with a dev that never has to go back and refactor because it just worked.

  • LZ79LRU (unregistered)

    Things like this remind me how much I miss the days before the internet was a thing for general consumption.

  • (nodebb)

    Here, we have PHP and JavaScript mixed together, like chocolate and peanut butter,

    Given it's PHP and Javascript, my thought is a dog turd and cat sick.

  • Memories... (unregistered)

    I actually worked in a team that maintained a similar codebase. It all started because one team member had previously developed a framework that we decided to use as it answered 90% of our needs at the time. And after that we just continued expanding it as needed, in the same style.

    Yes, having PHP generate JavaScript to create DHTML (as it was back then) content was... fun... We maintained near perfect stability by sheer force of being a (mostly) damned skilled group. And coffee. So much coffee. The office had cleaning staff dedicated to collecting and cleaning the mugs :-|

    Fun days. I hope this isn't still the same tool. Can't tell from the snippet, but it wouldn't look out of place.

  • (nodebb)

    Agree w mihi and Tyler W. Cox.

    BTDT in that era. Not with PHP exactly, but this has all the earmarks of a roll-your-own solution to the legit need that AJAX & JSON later filled.

Leave a comment on “JaphpaScript”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article