Over the weekend I added file uploading capability so now you can upload
your stylesheets and javascripts right into the database – Woo hoo!
This is my first stab at using Rails uploading and RJS so I’d really
love any feedback anyone has to offer.
You can get it here (while supplies last):
https://secure.svnrepository.com/s_swanki/open/radiant/extensions/styles_n_scripts/tags/latest
From the README…
The Styles 'n Scripts extension was an extension requested by John L.
as a means of separating javascripts & stylesheets from other site
content
stored in pages.
USAGE
Using this extension is rather painless. If you can use the rest of
Radiant,
using these additions should feel obvious. There are a couple of things
to take
note of, however.
-
The CSS and JS tabs are where you create, edit, and delete
stylesheets and
javascripts. But you need Administrator or Developer permissions to
see
these tabs. -
If you want to reference or otherwise use your script or stylesheet
in one
of your pages, there are <r:stylesheet> and <r:javascript> tags.
These tags
can be used to inject your CSS or JS code into the page or just
render a
link to the file itself. (Click the ‘available tags’ link when
editing your
Page to learn more about these two tags and their options). -
If you really want to get fancy with your CSS and JS files, you can
also use
the corresponding <r:stylesheet> or <r:javascript> to reference
other files
of the same type. So now you can create a single CSS or JS file
that is
made up of sub-files to cut down on server requests and speed up
page load
time – viola, now Radiant offers asset packaging just like Rails!
(And the
caching mechanism is smart enough to keep track of your file’s
dependencies)
That’s it. Everything else is either too obvious to bother with here or
automagical and/or too top secret to disclose ;-).
WHY CHANGE THINGS?
As John sees it, the pages tab is for storing your main content. (Think
of the
tree view as the list of available destinations for your users. Sure,
they need
stylesheets and javascripts, but those are supporting files – much like
images
– that augment your pages).
There are a number of interesting benefits gained by this approach:
-
CSS and JS files now get designer-level permissions – not
user-level. -
These files are now cached differently. Rather than the 5-minute
expiration
on pages, these files can now report to the browser the true
LAST-MODIFIED
date so we don’t have to serve up these files constantly. We can
put the
user’s browser caching to work. -
This properly separates the concerns of Pages and Text Assets. (I
mean, do
javascripts really need a layout or stylesheets a breadcrumb?).
Easier to
understand for the user and easier to develop for. -
Allows extensions to better interact with pages. For example, a
search
extension can now safely parse all the pages without search terms
like:
“background” returning all your stylesheets. -
Declutter the pages tree view so that it only shows what your
clients care
about – the things they’d aim their browser at (see John’s point
above). -
This opens the door for validation, minification and obfuscation of
scripts
and stylesheets (I’m thinking that these features belong in their
own
extension(s) but they’re much easier to build now that CSS and JS
distinct
objects).