[Radiant] [ANN] SnS Extension v0.4

[Chris Parrish]

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 Long
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).