Skip to main content

Publishing CSS or JS as Multimedia Components?

Let me start by saying that I am a strong believer that handling, uploading or publishing CSS or JS files as Multimedia Components is bad practice. At the same time I was recently surprised that opinions are actually quite different on the topic. There are people who don't always agree with me, shocker!!!

So I guess the point of this post is just to present the advantages/disadvantages of the two methods and see which you like best. Make that one best practice :)

Multimedia Components

In this approach, CSS or JS files are uploaded into Tridion as MMComponents based on a MMSchema. This is the default way the Dreamweaver mediator handles references to CSS or JS from an HTML (.dwt) document.

Advantages:
  • speed - easy to upload into Tridion, without having to create additional items like Schemas, Components, CTs, PTs, Pages;
  • easy to understand - developers with little Tridion experience understand this approach easier;
  • out-of-the-box - this is the default way the Dreamweaver mediator handles references to CSS or JS;
  • published automatically - when the referencing PT is published, all these MMComponents are published too automatically;

Disadvantages:
  • not elegant - treating text documents as binaries is an improper solution (binaries are treated like a black box, read-only, cannot be modified, need to be added as Multimedia Types, then added as allowed types in a MMSchema);
  • difficult to modify - MMComponents cannot be edited in Tridion, so you have to download them, modify them in an external editor, then upload them back into Tridion (note that you are forced into using _some_ external editor);
  • no version comparison - Tridion cannot compare MMComponent binaries;
  • overhead in publishing - whenever the referencing PT is publshed, all these MMComponents are published too, which can have bad consequences to publishing performance;

I think this is bad practice because it does not use the Tridion methodology of publishing text documents. In this approach, Tridion is nothing more than an FTP tool backed by a binary repository.

Components, CTs, PTs and Pages

In this approach, CSS and JS files are stored inside a Component text field (multi-line, no RTF). An embedded Component Template on the same Schema is used to output the text field. A Page Template specifies the file extension and outputs all Component Presentations. For each CSS and JS Components, you need a Page using the respective PT and on it, you place the Component with the Component Template.

Advantages:
  • control - this approach gives full control over the CSS and JS, e.g. by allowing image references to be resolved and published from within the CSS;
  • verison compare - possible to use because we are now dealing with textual representation;
  • publishing performance - CSS and JS are not published automatically when the referencing PT is published, therefore there is no performance degradation due to this fact;
  • editing capability - CSS and JS Components can be edited inside Tridion GUI (no external tool is needed);
  • follows Tridion methodology - this is the proper way of publishing things from Tridion (i.e. from Schema to Component to templates to Page);
  • elegant - this approach is clean, architecturally elegant, and it implements Tridion properly without cutting shortcuts into development;

Disadvantages:
  • slower development - this approach is not the default way the Dreamweaver mediator is using and more Tridion items are needed (e.g. Schema, Components, CTs, PTs, Pages);
  • not published automatically - when a referencing PT is published, the CSS and JS it not automatically published, rather a manual publish is needed;

This approach is the best practice.

Comments

Neil said…
What about not adding CSS/JS files into Tridion at all! (if you can).

Advantages:
Improved release management - cant forget to publish latest CSS/JS if its not in Tridion in the first place!
Tooling - editing CSS/JS in Tridion is horrible. Via WebDAV slight improvement. Files kept as part of VS solution edited in VS even better!
Cleaner development - all the application files part of VS solution, in source control, no where else.
Control - cant cut corners and publish out a "quick fix" to CSS/JS that could actually break a site in your clients eyes (even if functionally its fine)

Disadvantages:
Your might have lots of red tape to go through to deploy updates to a PROD server.
Binarybasher said…
Well, not to agree or disagree with either approach, I would still like to add my comment:

1. Automation is dependent upon your implementation, it's not a given. MMC or Text Component it can still be automatically published if required.

2. Tridion has moved the template development from scripts to binaries, allowing VS to be used instead if the Tridion GUI, why do you say toss is not "best practice" for CSS/JS ? I don't believe that is true. (caveat: you can continue to use scripted templates, especially XSLT, but for how long?)

3. I agree with the version comparison issue, but that should be a source system requirement there same add with compiled template assemblies. (you still have Tridion versioning)

4. Scripted CSS/JS gives you the dabble ability, good or bad you decide.

5. "elegant", not sure I would agree, both solutions offer elegance depending on your view... Some prefer modules and blocks, others prefer scripts (beauty is in the eye of the beholder, and all that jazz)

Tridion gives you flexibility and the building blocks to architect your requirements, methods that were good yesterday aren't always good for tomorrow.

You can make any method either work for you or not, but in this particular case I don't believe there is a right or wrong approach, having used both.

I would say, if using the MMC approach then consider publishing as dynamic component presentations, no need for pages as well.

Binarybasher
Binarybasher said…
Update (fixed typo's):

2. Tridion has moved the template development from scripts to binaries, allowing VS to be used instead if the Tridion GUI, why do you say it is not "best practice" for CSS/JS ? I don't believe that is true. (caveat: you can continue to use scripted templates, especially XSLT, but for how long?)

3. I agree with the version comparison issue, but that should be a source system requirement the same as with compiled template assemblies. (you still have Tridion versioning)
Mihai Cădariu said…
This is a valid approach too. However for CSS, I would actually prefer to use Dreamweaver or another HTML editor, rather than VS.

Not sure I agree with 'control': you can always cut corners, don't test enough, make mistakes, etc. In this case, a mistake will be harder (take longer) to solve due to the red tape you mention.
Mihai Cădariu said…
Good comments! This proves to me once again that this is a hot topic.

My main issue with JS/CSS as MMC is the misuse of types. Why put a text file inside a binary format? With this rationale we could consider everything being a binary file. This is what I don't find elegant.

Not sure I understand #2 -- do you mean scripts as in old school VB/JS scripts? We still have DWT including its Expressions Language that generates the output, which is ultimately still a script.

Finally, I don't think publishing MMC JS/CSS as DCPs is viable due to the fixed file extensions they have when published. For this to work, we would need some deployer/storage extensions or dynamic CD code to include them into the HTML.
Nivlong said…
Regardless of approach, I think buy-in also depends on an organization's existing processes and especially on who "owns" these files.

In situations where Web and CMS development are consolidated (e.g. my Tridion VM), I'd want styles and script centrally located. But if we have distinctly separate developer and designer teams, I can see why JS/CSS as MMC is appealing.

If treating JS/CSS as text in Tridion, I'd recommend at least training or some automation that lets designers work in ways that are familiar to them. Maybe a simple script that "pushes" local dev changes to the DEV CMS (check time stamps, read files, create corresponding components, etc), for example.

Then Tridion could remain a "black box" to designers, chief editors can control releasing page and maybe design changes, and developers/IT get managed web-related files in Tridion.

Popular posts from this blog

Toolkit - Dynamic Content Queries

This post if part of a series about the  File System Toolkit  - a custom content delivery API for SDL Tridion. This post presents the Dynamic Content Query capability. The requirements for the Toolkit API are that it should be able to provide CustomMeta queries, pagination, and sorting -- all on the file system, without the use third party tools (database, search engines, indexers, etc). Therefore I had to implement a simple database engine and indexer -- which is described in more detail in post Writing My Own Database Engine . The querying logic does not make use of cache. This means the query logic is executed every time. When models are requested, the models are however retrieved using the ModelFactory and those are cached. Query Class This is the main class for dynamic content queries. It is the entry point into the execution logic of a query. The class takes as parameter a Criterion (presented below) which triggers the execution of query in all sub-criteria of a Criterio

A DD4T.net Implementation - Custom Binary Publisher

The default way to publish binaries in DD4T is implemented in class DD4T.Templates.Base.Utils.BinaryPublisher and uses method RenderedItem.AddBinary(Component) . This produces binaries that have their TCM URI as suffix in their filename. In my recent project, we had a requirement that binary file names should be clean (without the TCM URI suffix). Therefore, it was time to modify the way DD4T was publishing binaries. The method in charge with publishing binaries is called PublishItem and is defined in class BinaryPublisher . I therefore extended the BinaryPublisher and overrode method PublishItem. public class CustomBinaryPublisher : BinaryPublisher { private Template currentTemplate; private TcmUri structureGroupUri; In its simplest form, method PublishItem just takes the item and passes it to the AddBinary. In order to accomplish the requirement, we must specify a filename while publishing. This is the file name part of the binary path of Component.BinaryConten

Scaling Policies

This post is part of a bigger topic Autoscaling Publishers in AWS . In a previous post we talked about the Auto Scaling Groups , but we didn't go into details on the Scaling Policies. This is the purpose of this blog post. As defined earlier, the Scaling Policies define the rules according to which the group size is increased or decreased. These rules are based on instance metrics (e.g. CPU), CloudWatch custom metrics, or even CloudWatch alarms and their states and values. We defined a Scaling Policy with Steps, called 'increase_group_size', which is triggered first by the CloudWatch Alarm 'Publish_Alarm' defined earlier. Also depending on the size of the monitored CloudWatch custom metric 'Waiting for Publish', the Scaling Policy with Steps can add a difference number of instances to the group. The scaling policy sets the number of instances in group to 1 if there are between 1000 and 2000 items Waiting for Publish in the queue. It also sets the