tags:

views:

82

answers:

4

I have an Ajax-enabled CRUD application. If I display a record from my database it shows that record's values for each column, including its primary key.

For the Ajax actions tied to buttons on the page I am able to set up their calls by printing the ID directly into their onclick functions when rendering the HTML server-side. For example, to save changes to the record I may have a button as follows, with '123' being the primary key of the record.

<button type="button" onclick="saveRecord('123')">Save</button>

Sometimes I have pages with Javascript generating HTML and Javascript. In some of these cases the primary key is not naturally available at that place in the code. In these cases I took a shortcut and generate buttons like so, taking the primary key from a place it happens to be displayed on screen for visual consumption:

...
<td>Primary Key: </td>
<td><span id="PRIM_KEY">123</span></td>
...
<button type="button" onclick="saveRecord(jQuery('#PRIM_KEY').text())">DoSomething</button>

This definitely works, but it seems wrong to drive database queries based on the value of text whose purpose was user consumption rather than method consumption. I could solve this by adding a series of additional parameters to various methods to usher the primary key along until it is eventually needed, but that also seems clunky.

The most natural way for me to solve this problem would be to simply situate all the Javascript which currently lives in external files, in the <head> of the page. In that way I could generate custom Javascript methods without having to pass around as many parameters.

Other than readability, I'm struggling to see what benefit there is to storing Javascript externally. It seems like it makes the already weak marriage between HTML/DOM and Javascript all the more distant.

I've seen some people suggest that I leave the Javascript external, but do set various "custom" variables on the page itself, for example, in PHP:

<script type="text/javascript">
var primaryKey = <?php print $primaryKey; ?>;
</script>
<script type="text/javascript" src="my-external-js-file-depending-on-primaryKey-being-set.js"></script>

How is this any better than just putting all the Javascript on the page in the first place? There HTML and Javascript are still strongly dependent on each other.

+7  A: 

one point: an external file can be cached by the browser, a js-block in the head is loaded every time the file loads.

oezi
For jQuery and other libraries I do this without issue, but that is generic and isn't coupled with any of my app-specific rules/logic. Efficiency aside, how does this complete separation make app-specific JS more readable/maintainable?
RenderIn
+1  A: 

You can YUICompress your javascript (at build/integration time) if it's in separate files. I smash all my Javascript together (lots of separate little jQuery plugins etc) at build time so that there's just one file to fetch/cache.

Pointy
+3  A: 
  • Performance (due to browser caching)
  • Separation of concerns - HTML/CSS/JavaScript should be separate. It makes working with them easier. You know exactly where to locate certain areas, plus other developers can work on the likes of HTML, CSS and JavaScript independently.
  • Reuse - you can include a source file in multiple locations/projects without duplicating code.
Finglas
Where should the code live which calls an JS function to highlight a field, then remove it from the screen and print a 'Row XYZ deleted' message to a div, live? Should this be in the onclick function? I don't see how things like this can live anywhere but in the HTML, since they (the calls to the functions that do these things) are not reusable at all.
RenderIn
@Render: the "code" in the actual HTML should consist of nothing but a function call; all the logic can and should be encapsulated in the function definition, which then can live elsewhere. It would be useful to use a different function name for each style, e.g. onClick_styleFoo, onClick_styleBar etc.
Ether
What Ether said, sums up my thoughts exactly.
Finglas
+1  A: 

It depends on how much Javascript are you dynamically generating on the server-side versus how much of it is static. If all of it is dynamically generated, then it doesn't matter where you put them as every request will pull a new file without any caching. Putting it in the head has the advantage of one lesser HTTP request which is hardly any benefit unless you're primary concern is performance and bandwidth is a non-issue.

But if most of the Javascript is static, keeping it in separate files at development time keeps things organized.

Dynamically generated Javascript can be served as separate files instead of being part of the page itself. It will add an extra HTTP call.

<script src="myServerSideScript.php" type="text/javascript"></script>
Anurag