On Mon, Jan 16, 2012 at 05:28:45AM -0800, Martin Stein wrote: > For the current project at work, we are looking into using require.js > (http://requirejs.org/) to combine, modularize and minify our > javascript. So, basically, we need to have a server-side build step > before serving our static files. Our plan is as follows: > > - have our pre-build javascript files in the usual '/static' directory > - put the results from require's optimizer to a '/static-build' > directory. (The require.js docs recommend a separate directory.) > > Depending on development or production scenario (taken from .ini- > file), the static files should be served from one or the other > directory. However, so far I don't see a nice approach to this. When > we started the project, we used the normal Pyramid approach in our > templates. In our __init__.py, we have something like: > > config.add_static_view('static', 'myproject:static', > cache_max_age=3600) > > In the jinja-template, we created the links with > > <script src="{{request.static_url('myproject:static/js/ > application.js')}}" type="text/javascript"></script> > > But if the directory changes from 'static' to 'static-build', we would > have to change all our static_url(..) calls. Is there a way to make > the resource 'myproject:static' refer to a different directory, > depending on .ini configuration? > > One approach would be to read the resource directory from the .ini > file and add the static view like this: > > config.add_static_view('static', RESOURCE_FROM_INI, > cache_max_age=3600) > > Then, you could refer to the files like this: > > <script src="{{ request.script_name }}/js/application.js'" type="text/ > javascript"></script>
I think {{ request.application_url }}/js/application.js is more
appropriate here.
> (note that you need the 'script_name', because on the production
> server your application might be deployed under a URL prefix). But the
> 'request.script_name' approach looks kind of hacky to me and it means
> we'd have to replace all our static_url(..)-calls. Do you see another
> way to do this elegantly?
>
> The trend for larger javascript-heavy apps seems to be going towards
> require.js, so I think a nice solution for this problem will be
> interesting for lots of people.
/me is listening with interest
Marius Gedminas
--
Colorless green ideas sleep furiously.
signature.asc
Description: Digital signature
