I've always wondered if there's a "preferred" way to manage CSS and Javascript files in Tridion. I have mine (do whatever is best for the customer's requirement) but maybe there's some kind of "best practice" that I am not aware of.
So, should I store the css and js within Tridion or managed them (deploy them) using a different mechanism? Should a treat them as binaries or content?
I'm not sure there is a correct answer here... i think it's based on the client needs.
Here's an opinion...
It's now possible to store binaries in the broker database, it makes a great case for managing them in the CMS, so that external 'consumers' (development teams, partner websites, load balanced machines, etc) can consume / store these files and receive instant updates when published.
If you store files outside of the CMS, you'd have to ensure your local 'consumers' are constantly receiving the latest files and manually deploying them to the file system.
I agree with John that it would be based on the clients needs, but also in relation to what development and deployment model you have chosen.
When looking at the different implementation options, I like the simplicity of having HTML in your (DWT) Templates and then often will go for Publishing CSS and JS as Pages (personally hate the idea of using Multimedia Components for them). In one of my last workshops I showed two options for that:
Using a Component with a single Text field for the JS, so you had the option to combine multiple JS scripts (as Component Presentations) on a single JS Page.
Using a Page Template for the CSS, the CSS was directly in a DWT TBB, and all the image links are resolved by the default TBBs (so using a single PT per CSS file and an 'empty' Page to Publish it).
But while this works in a training and demo very well (also is easy to explain to people), I would not necessarily choose that model for a large production website. When looking at that, you probably choose a web application model, say for instance DD4T and there you deploy CSS and JS as part of your web application, so it will stay completely outside of the CMS.
Here is the logic that I use with clients (and chiming in with what Alvin said):
C# is code, therefore belongs in a code repository (e.g. SVN). Java is code, therefore belongs is a code repository. SQL scripts is code, therefore belongs is a code repository. .... should I go on?
So what makes JavaScript or CSS any different? It is code that also needs to be tested and debugged.
The biggest reason that clients ask to keep JavaScript and CSS in Tridion is to bypass their IT's painfully slow Release Management processes. They want quick and timely front-end updates, for example to Marketing promotions, without having to wait 3 weeks. But relying on the Deployer to get this "code" released to Production without a full-on Release Management Process is a cheat (otherwise you wouldn't need the process), otherwise they would simply get FTP access to Production Presentation Servers. So I always caution clients that if they want to store CSS and JS in the CMS, then there are serious risks they need to consider and mitigate.
I'd personally keep them outside Tridion because both Javascript or CSS files do not really relate to the content managed in the CMS, specially when using a framework such as DD4T
I think Bart and John did a good job explaining the mechanisms of how to deal with CSS/JS. I want to chime in regarding whether to publish them as binaries or not.
I am a strong believer that you should not store CSS/JS as binaries (i.e. Multimedia Components). I don't think it's the right way. The whole contention point starts with the way these assets are created by Tridion when using the Dreamweaver a.k.a. WebDAV connector to upload a DWT TBB that refers to CSS/JS/Image assets. While it makes a lot of sense to store images as MMCs (doh!), I see it as a shortcut to create MMCs also for JS and CSS.
This is great demo material and it shows how easy it is to import your existing HTML markup & related files into Tridion. However, there is a lot of effort ahead to make it a content managed solution. That includes creating Schemas and CTs for JS/CSS or PT and DWT TBB (as presented by Bart).
On the other hand, if you consider it's too much work creating all these items, especially if you won't manage or modify the CSS/JS within Tridion, then probably it's best not to store it in the Content Manager in the first place (as John suggests).
A few points why it would be beneficial to have JS/CSS in Tridion and in textual representation:
Considering the fact that you need script and styles all across DTAP (Dev, Test, Acceptance, and Production), JS and CSS files should probably follow the same development processes as application code.
The biggest benefit to placing these in the CMS is the "managed" part, which echoes Mihai's points:
You only get text-based comparisons if these are actually text in the CMS. But I'm not quite sure multimedia or even code components are the best solution either.
Ideally we'd have:
So maybe if you can get a .css and .js as a text-based "item type" (doesn't exist, right?) in the CMS, you can make a new best practice.
Tweak your setup of people, process, and technology enough and you can legitimately break any of the rules in the name of business needs. Promos, for example, break all the rules and may include everything from custom code, custom stylesheets, and never-updated content (in forms with hundreds of fields). :-P
