processing external files for multiple users

Forum Moderators: open

Message Too Old, No Replies

processing external files for multiple users

sssweb

8:53 pm on Jun 8, 2012 (gmt 0)

I assume this isn't an issue, but I can't help wondering:

I have a PHP script that dynamically generates javascript (actually jQuery) code based on a user's request and writes it to an external file. It then finishes processing the page and displays it. On the page, there may be one or more click events that rely on the jQuery in the external file.

My question is this: if a different user requests a page that tells the PHP script to write different jQuery code to the same external file, and this happens AFTER the first user's request but BEFORE the first user clicks on the click event, will the jquery processing fail because it's been updated by the second user?

Seems like that would be a major web design hurdle. My guess is that the first user's browser caches the whole thing at pageload and doesn't rely on later access -- is that correct?

nameisbrian

6:41 am on Jun 9, 2012 (gmt 0)

So as long as the user doesn't do a hard refresh (f5), it might be fine. A much better solution would be to put the code in separate files, then generate a new page with the

src

attribute changed on your script element. You can also change the

script

element dynamically with JavaScript:


...
<body>
<script id="my_script" src="one.js"></script>
<button id="change_script">Change Script</button>
<script>
document.getElementById('change_script').onclick = function() {
document.getElementById('my_script').src = undefined;
var script_element = document.createElement('script');
script_element.src = 'two.js';
document.body.appendChild(script_element);
}
</script>
</body>
...

sssweb

2:10 pm on Jun 9, 2012 (gmt 0)

Thanks for the reply. A couple questions:

First, to clarify, are you saying this IS a potential problem? I can't believe I'm the only website owner who has this setup. And I don't see why an F5 refresh creates problems -- that would re-generate the script w/correct settings; at worst, the same issue as before recurs -- it doesn't change anything.

By putting the code in separate files, do you mean have the PHP script generate a separate .js file for each user and link each user's click event to a unique file? Seems like that creates a LOT of server files.

Can't comment on your dynamic script element -- that's out of my league; need something simpler.

If this is definitely an issue (i.e. the browser does NOT cache all external script files for use on future click events), please confirm -- I may end up dumping the external files altogether and just print the js to the page.

sssweb

5:39 pm on Jun 9, 2012 (gmt 0)

In thinking more about this, it seems impossible that the browser doesn't cache all external files. If it didn't, then when the user clicks on the click event, the page wouldn't find the function. I can't believe that it would only then search the external file refs for it.

Isn't that correct?

nameisbrian

9:10 am on Jun 11, 2012 (gmt 0)

Generally, the browser reads elements top to bottom (or works that way), when it runs into the script element, it'll look at the src attribute and download that file (of course this is different when you have defer and async set on your script element).

Once the script has been downloaded and executed, this is when event handlers can be invoked. This will continue on, whether the file is cached or not. If the file has been changed, the events will still work, as the browser has not redownloaded the changes. If the user clicks away and comes back, they will be presented with whatever file was generated last.

I do not know too much about caching. To my knowledge, if the user refreshes, the same JS file will be used even if it has been changed. If they do a hard refresh, usually f5, then the files will be requested again even if they haven't been changed. When the file is cached, and the file hasn't changed, leaving and coming back to the file will have the server respond with a "304 Not Modified". This information needs to be verified, as I am just saying this off the top of my head with little research in how caching works.

The way you described what you were doing, it sounds like you are having a PHP script output data to the same file, instead of having PHP code in the file to generate the content. This can cause other issues. For example, what if multiple users are requesting a change? The file would be locked because PHP is still editing it.

To get around this, your PHP code should be in the JS file, or should be generating inline scripts in your HTML file, instead of generating a file and outputting it.

As far as my suggestion in my first post goes, I was thinking you were allowing a user to select a few static libraries. If you are, then my first post is the best option. Now, I am assuming that your JS code is dynamically changed based on user options, in which case, you wouldn't be able to easily generate a bunch of static files since there are too many changes to consider. However, generating a file that a user creates is really not a big deal. You could store the locations of the files in a database and delete them overtime.

rlange

2:57 pm on Jun 11, 2012 (gmt 0)

If I'm understanding the setup correctly, there's also a potential issue where User A makes a request, causing this file to be updated, but before User A's browser can request that file, User B makes a request that alters the file.

User A now has a script customized for User B and, as a result, a page with some broken functionality.

--
Ryan

sssweb

3:15 pm on Jun 11, 2012 (gmt 0)

Thanks for taking time to explain all that. I think you've got it right -- the user lands on a .php page that generates display and also javascript, written to an external file, to run click events on the page.

You say this can cause problems if multiple user request a change. (FYI before getting to your main point here, my PHP 'locks' the .js file while editing, so other requests can't interrupt.) Is that really different than multiple users requesting the same php page which must generate user-specific display? Or are you saying that external file-writing requires more processing time, and so creates a back-log with many requests?

Re your solution to generate inline javascript in my HTML file (actually it'd be in <head>), that's easy enough to do -- in fact, it's the back-up action in my PHP script if the external file-write fails. The reason I opted for the external file as first choice is that I thought it was cleaner coding to separate js from html, and to keep the source code private. Are you saying that in this case, the other issues override that?

I'll look into generating user-specific external files; can you give me a heads-up as to the php functions for this? Otherwise, I'll post in the PHP forum if I can't find it myself.

Thanks for your help.

sssweb

3:21 pm on Jun 11, 2012 (gmt 0)

Update - found the PHP functions: file_ put_ contents() to create/write [already using], and unlink() to delete.

Fotiman

4:02 pm on Jun 11, 2012 (gmt 0)

It sounds as though you do have a potential race condition. For example:
1. User A visits the PHP page.
2. The PHP page locks the .js file
3. The PHP page writes to the .js file
4. The PHP page releases the lock on the .js file
5. User B visits the PHP page.
6. The PHP page locks the .js file
7. The PHP page writes to the .js file
8. The PHP page releases the lock on the .js file
9. User A's browser performs the HTTP request for the .js file and gets the version meant for User B
10. User B's browser performs the HTTP request for the .js file and also gets the version meant for User B.

It's a very small window, but none the less, there IS the potential for error.

Note, this is different from multiple users requesting the same php page, because each request is tied to a particular session. In this case, though, you're generating a .js file which is going to be requested via a separate HTTP request. A PHP page contains code that processes a request and generates output specific to the session, but a request to a .js file is only going to fetch the latest version of that file from the server, which in your case may get over written.

sssweb

5:08 pm on Jun 11, 2012 (gmt 0)

Thanks everyone for input on this -- I see the point and will either write the js directly to the HTML file from php, or create & delete user-specific external js files.

Unless anyone has a comment on which solution is best (or the best way to do it), we're done.

rlange

4:22 pm on Jun 13, 2012 (gmt 0)

You could re-purpose the PHP script to output the JavaScript directly and then include that PHP script in your HTML document, like you would a normal JS file. (Depending on how you retrieve the user-specific data used to generate the JS, though, you may be duplicating some code, which isn't always a good idea.)

<script src="/scripts/delete-user.js.php"></script>

The

delete-user.js.php

script would do almost exactly the same thing as your current code, except it will

echo

the JS instead of writing it to a file.

You'll probably want to explicitly declare the content type before

echo

ing anything, though.

<?php // delete-user.js.php

header( 'Content-type: application/javascript' );
echo $js;

?>

I'm pretty sure there are other headers that would be good to set, but I can't think of them off the top of my head.

--
Ryan

daveVk

2:14 am on Jun 14, 2012 (gmt 0)

Writing the js directly to the HTML file avoids lots of pain and complexity, what is the negative side ?

Would also look at what js content is not dynamic, or does not need to be dynamic and serving as static (cachable) file. A little refactoring may remove most if not all.