about refactoring (aka oh right i need a title)

[dunvi]

I was looking at two seemingly similar bugs: bug 3838 and bug 3839, both of which have to do with breaking out JS (and in the case of 3838 CSS) from BML pages.

There was some talk of possibly porting the whole thing to the TT, but, gotta say, there are probably easier ones to start learning TT on!

Anyway. 3838 went fine - easy enough to remove the JS and CSS and move them into their own files. 3839 is a different story. Though the two look very similar, the way the JS is both implemented and then used is very different, and after a lot of thinking and futzing around, I have come to the conclusion that I cannot simply move the JS to a different file and tell the BML file where to find the JS.

In both cases, the JS is looking for information in the associated .text file. In 3838, this isn't important, because what the JS did was generate the HTML to be inserted into the page, which means that the perl inside still had a chance to be read properly. In 3839, the JS is causing actual events - for example, pop-ups asking you to input a name.

I guess there's several ways, then, to 'solve' this particular page. The easiest one is to leave it be and say "The javascript's just stuck". The hacky solution is to alter three of the javascript functions so that they take in some inputs, pre-gather the information from the .text file, and pass it to the javascript functions. Perhaps the correct answer is to rewrite the JS entirely, at which point I would say "Teach me how to convert this to TT".

Surely this problem has been encountered before?

Comments

Yes, this has been encountered before

[allen]

Just to make sure: the problem that you're seeing is that there is some localized text that is accessed from the translation system that is then shown via JavaScript, right? So if you try to move that JS entirely to a separate file, then you lose the access to the localized strings?

I've run into that several times. Unfortunately, to my knowledge, we haven't come up with a full solution to showing localized strings from our JavaScript. I've worked around this in two ways in the past: if the strings are static, I've just put them directly into the JavaScript and accessed them through there (see $.threadexpander.config.text.error_nomatches in htdocs/js/jquery.threadexpander.js). In another case, I put the messages in a little bit of JavaScript in the header (see, say, cgi-bin/LJ/S2/FriendsPage.pm and look for expanded). Neither of these are really a good solution, but then, they're not really _that_ terrible.

(And for reference, you'd be running into this problem even if you were converting the file to TT; the generated HTML is still the dynamic part, and the JavaScript file should still be static, and the JavaScript is still going to need to get some localized values somehow from the translation system....)

Re: Yes, this has been encountered before

[foxfirefey]

Well, drat! I thought that we had a solution to these and I just didn't know it. At least I don't feel silly for not knowing it now!

Re: Yes, this has been encountered before

[sophie]

I've done the same thing. If you look at dw-nonfree/htdocs/index.bml , you'll see that I do this:

        $headextra .= <<HEAD;
<script type="text/javascript">
    var ml = new Object();

HEAD
        $headextra .= "    ml.joinheading = \"" . BML::ml( ".create.join_dreamwidth",  { sitename => $LJ::SITENAMESHORT } ) . "\";\n";
        $headextra .= <<HEAD;
    ml.entercode   = "$ML{'.create.enter_code'}";
    ml.usecode     = "$ML{'.create.use_code'}";
    ml.cancel      = "$ML{'.create.cancel'}";

HEAD
        $headextra .= "    var invitelength = " . DW::InviteCodes::CODE_LEN . ";\n";
        $headextra .= "    var siteroot = \"" . $LJ::SITEROOT . "\";\n";
        $headextra .= "</script>\n";

That causes it to make output that looks like this:

<script type="text/javascript">
    var ml = new Object();

    ml.joinheading = "Join YourSite";
    ml.entercode   = "Enter your invite code:";
    ml.usecode     = "Use Code";
    ml.cancel      = "Cancel";

    var invitelength = 20;
    var siteroot = "http://www.daily.hack.dreamwidth.net";
</script>

I can then use ml.joinheading and such in the JavaScript to refer to the strings.

Re: Yes, this has been encountered before

[exor674]

Be aware that the ML strings really should be ejs / ejs_string'd.