We Keep Coding

Grabbing HTML from another page

I have two HTML files: One acts as a template, supplying the navigation, sidebars, etc., and the other has the main content. I'm trying to figure out how best to insert the content into the template. I need persistent URLs, so my plan was to have the content page essentially replace itself with the template, plugging the text back into the resulting page. I'm really new to front-end programming and I'm suspicious that this may be an anti-pattern, so my first question is about whether I'm barking up the right tree. The problem seems universal, and I'm sure there must be a best practice, though I haven't yet seen it discussed. If this is an acceptable way to proceed, then what JavaScript function would allow me to access the HTML of two different pages at the same time?
[EDIT: It's a small page on GitHub]

Do not do this. At current implementation HTML is not designed to be template engine. You can use HTML import but it has not full support in browsers. (compatibility table).
Usually this problem can be solved with:
Use frontend framework. Libraries like angular.js or polymer.js (and so on) usually has support of importing HTML documents in different forms.
Build your application HTML. Task runners like grunt.js usually has plugin that includes HTML.
Use server side technologies to extend your HTML from base layouts
If your application have to be consisted from different HTMLs I recommend you to try polymer. It is polyfill for web components and designed to work in such way by default.
UPD:
About edit to your question. It seems like you just need template engine for HTML. You can google for it. I use nunjucks - javascript port of python's template engine jinja2. It is lightweight, simple and can be compiled right in browser.
Another way is to use special tools for building static web pages. You have mentioned that your page is blog build from simple HTML pages. Try to use pelican. It is the static websites (blogs) generator. It is simple and fast. You can build your HTML even on your local machine and just push your HTML pages to github.

Django : Is it a good idea to generate JS dynamically?

When I write my JS files for a Django project, of course I do some AJAX calls, and for the moment the urls for those calls are hard-coded (which is very ugly).
I was thinking of having the JS files served by django (instead of Apache), so I could take advantage of the template tags ({% url %} !!!).
Is there a reason why I shouldn't do this ?
Or is there a right way to do this ?
(I can give a least one : it will consume a lot of time resending JS files that haven't changed. What would be great is to have an application that generates files when restarting django server, and serves them statically after !)

I would go for a hybrid technique. Serve most of your javascript statically. But in your Django template, have a <script> block that defines various global variables, which are generated by the server-side code - url is a good example. Then your static JS can refer to the variables that are generated in the dynamic code.

I searched deeper in those asset manager applications from djangopackages, have found out that django-mediagenerator provides that feature, even if it is not well documented : you can generate your js or css files as django templates, and then serve them statically (they are also bundled, and caching is managed etc ... so two birds with one stone + it is really easy to set-up !).
In order to have JS files generated as django templates (after having set-up django-mediagenerator), just add the filter :
ROOT_MEDIA_FILTERS = {
'js': 'mediagenerator.filters.template.Template',
}
in your settings.

Dynamically generating Javascript on your server can be a tremendously powerful tool and I've experienced both it's upside and downside in my projects.
In general you want to keep as much as possible static to minimize the work to be done on every request. This includes having the browser cache as much as possible, which might become a problem in your case.
What I usually do is to have a block in the header in my base template. In templates that need to do custom javascript that is only known at runtime (customization based on logged in user, for example), I add it to the block. Here I can dynamically generate javascript that I know won't be cached so I can make some assumptions. The downside is more complexity.
If what you need are just pointing to urls, or have some simple configuration, etc, then I would suggest creating a view that will return a Javascript file with these settings. You can set the correct headers(Etag, Cache-Control, etc) so the browser will cache the file for some reasonable time. When you upgrade your code, make sure the Etag will change.
In the code that needs to use the configuration, you need to always check that the variable you are looking for is actually defined otherwise you will run into problems that are hard to debug when for some reason the configuration javascript is not loaded correctly.

The .js that gets sent to the browser would vary. That could make debugging more cumbersome. Maybe not a problem but something to potentially consider...

Nowadays, the best way to do this is to use Django.js
Here is the doc where they talk about the URL reversing: http://djangojs.readthedocs.org/en/0.8.1/djangojs.html#reverse-urls

Javascript code management in asp controls

We're looking for a way to manage ever-increasing javascript code for our asp controls (used with RegisterClientScript family). The classic way was to have javascript encoded into string constants inside c# code but now it's getting bigger and you don't want to develop inside c# string. Having code in external file and convert/copy it into a string form before compilation is also somewhat ridiculous. Plus in these scenarios almost same code is sent several times with each instance of the control.
Other important criteria is to have the scripts self-sufficient, with only external dependency on jquery&co, so having control-specific javascript files somewhere else is not desired. All the relevant parts have to be in one place.
My personal best option so far is to have Javascript split into two parts:
- "code behind"-like js file compiled as embedded resource into assembly. This is about 3 times slower than string concatenation but. Plus it brings options for caching and direct-from-file without recompiling for debugging. This part is delivered inline once per page containing the control.
- tiny initialising proxy function calling the main script with control-instance specific parameters. These are delivered also inline but once per control instance.
I'm sure we're not the only ones scratching our heads about this.
So how do you do that?
Update.
Getting rid of .net specifics, situation is following.
We have some 100+ reusable server-side components each possibly containing some javascript client-side functionality. These controls are of course not used in every page so packing the javascript into one common lib is not desired. On the other hand, having 20+ references to external javascript files each being 1-2Kb in size is also both headache for maintenance and traffic overkill.
That is why we want to have the component know and care about its own javascript inclusion.
On the other hand, if you have a project where these components are spread into several libraries, you don't really want for them to depend on some particular filesystem layout which may be of course standardised but it's too much of responsibility for a vehicle tire to enforce your cola choice in a diner, imo.

If you have JavaScript code that is re-used by several controls - why don't you want this in an external *.js file? This will allow you to maintain formatting, and yet still serve up a minimized, gzipped and client side cachable file.

best practice for dealing with common "structural" elements of pages?

Very basic question: I am coding a web app that has a handful of pages. These pages have the usual shared elements: eg, the site's header/masthead and a side-bar are present on all pages. The HTML is static (not dynamically generated, its "ajaxy-ness" is done client-side).
What is the best way of importing/"including" those common elements into my pages? The solution I am using is to have the HTML files contain empty place-holders
<div id="header"></div>
<div id="leftSideBar"></div>
(...)
and then do in jquery's $(document).ready():
$.get("header.html", function(html) { $("#header").html(html); });
// ....
Is this the best way to do this? I'm new to web development. : )
I guess I could also dig up a "macro-like" code-generation tool that I would run on the HTML files to replace, eg, "#header" with the contents of header.html. That way loading a page would require a single request for a single HTML file, which sounds better.
What is the smart way to achieve this? I am sure this problem has been solved a thousand times.
EDIT: The server-side is coded in Python+cherrypy. (I am assuming it is reasonable to try to keep away from dynamically generating HTML when doing "web 2.0-ish" web apps. Please correct me if I am wrong. As I said, I am very new to this environment.)
Thank you for your insights,
lara

If you want to include files, please consider using some backend language such as PHP or ASP. Javascript is not really meant to do this even if this would work.
<?php include 'other_file.php'; ?>
Using javascript to do this will lead, I think, to a poor SEO and the loading of the page might look weird for the end user. If you really don't want to use a backend language, some IDE have a way to handle templates, you could look into that.
Concerning frameworks, most of them have a way to handle templates. ASP.NET has the master page system, Ruby on Rails has layouts.
Here's an example using Rails :
<html>
...
<div id="content"> <%= yield %> </div>
...
</html>
Here all the content of a subpage will go into the "yield". Here's a link to learn more about that.
Some frameworks can handle multiple place holders.

To some extent, it depends on what you're using on the server side to render the pages. If your using server side scripts to generate the page you should be able to use a web framework (eg. Django or RubyOnRails) or even just a basic templating engine such as Genshi. Basic include functionality may even be built into the language you're using (ie. PHP)
If it's just static HTML you may want to look into setting up some form of server side includes such as Apache SSI or NGINX SSI. You'll need to pick the one that works with whichever server you're using, and you'll need enough access to install and configure the plugin or module.
Alternatively, you might want to look at using a script to generate your pages (edit, generate and deploy). A simple approach using cat / sed / awk / make (additional useful reference - Sed & Awk) may be all you need, or you might want to use a templating engine and a language such as Python or Perl.

I'd have the includes handled server-side, and this will mean fewer requests from the client, and may also have other benefits (easier to debug js, etc).
Having the server process includes really isn't going to put a major strain on it.

YUICompressor or similar in PHP?

I've been using yuicompressor.jar on my test server for on-the-fly minimisation of changed JavaScript files. Now that I have deployed the website to the public server, I noticed that the server's policies forbid the use of exec() or its equivalents, so no more java execution for me.
Is there a decent on-the-fly JS compressor implemented in PHP? The only thing resembling this that I was able to find was Minify, but it's more of a full-blown compression solution with cache and everything. I want to keep the files separate and have the minimised files follow my own naming conventions, so Minify is a bit too complex for this purpose.
The tool, like yuicompressor, should be able to take either a filename or JavaScript as input and should either write to a file or output the compressed JavaScript.
EDIT: To clarify, I'm looking for something that does not have to be used as a standalone (i.e. it can be called from a function, rather than sniffing my GET variables). If I just wanted a compressor, Minify would obviously be a good choice.
EDIT2: A lot has changed in the five years since I asked this question. Today I would strongly recommend separating the front-end workflow from the server code. There are plenty of good tools for JS development around and except for the most trivial jQuery enhancements it's a better idea to have a full workflow with automated bundling, testing and linting in place and just deploy the minified bundles rather than the raw files.

Yes there is, it's called minify.
The only thing in to worry about in the way of complexity is setting up a group, and there's really nothing to it. Edit the groupsConfig.php file if you want multiple JS/CSS in one <script> or <link> statement:
return array(
'js-common' => array('//js/jquery/jquery-1.3.2.min.js', '//js/common.js', '//js/visuals.js',
'//js/jquery/facebox.js'),
'css-common' => array('//css/main.css', '//css/layout.css','//css/facebox.css')
);
To include the above 'js-common' group, do this:
<script type="text/javascript" src="/min/g=js-common"></script>

(i know i was looking for the exact same thing not knowing how to deal directly with the jar file using php - that's how i ended up here so i'm sharing what i found)
Minify is a huge library with tons of functionalities. However the minifying part is a very tiny class : http://code.google.com/p/minify/source/browse/trunk/min/lib/Minify/YUICompressor.php
& very very easy to use :
//set the path to the jar file
Minify_YUIcompressor::$jarFile=_ROOT.'libs/java/yuicompressor.jar';
//set the path to a writable temp folder
Minify_YUIcompressor::$tempDir=_ROOT.'temp/';
//minify
$yourcssminified=Minify_YUIcompressor::minifyCss($yourcssstringnotminified,$youroptions)
same process for js, if you need more functionalities just pick from the library & read the source to see how you can make direct call from your app.
I didn't read the question well, since minify is based on using the jar files, the op can't use it anyway with his server config
Minify also include other minifying methods than yui, for example:
http://code.google.com/p/minify/source/browse/trunk/min/lib/JSMinPlus.php?r=443&spec=svn468

Try Lissa:
Lissa is a generic CSS and JavaScript loading utility. Lissa is an extension of the YUI PHP Loader aimed at solving one of the current loader limitations; combo loading. YUI PHP Loader ships with a combo loader that is capable of reducing HTTP requests and increasing performance by outputting all the YUI JavaScript and/or CSS requirements as a single request per resource type. Meaning even if you needed 8 YUI components which ultimately boil down to say 13 files you would still only make 2 HTTP requests; one for the CSS and another for the JavaScript. That's great, but what about custom non-YUI resources. YUI PHP Loader will load them, but it loads them as separate includes and thus they miss out on benefits of the combo service and the number of HTTP requests for the page increases. Lissa works around this limitation by using the YUI PHP Loader to handle the loading and sort of YUI and/or custom resource dependencies and pairs that functional with Minify.