I’ve posted a new Beta release on CodePlex, you can get it here: http://clientdependency.codeplex.com/Release/ProjectReleases.aspx. On the releases tab includes a sample web site that has most of the functionality that you can do so please download it for a documentation reference.

Newest changes & additions

• Namespace and codebase changes/steamlining
• Proper versioning added
• Versioning is done on a global basis in the config
• Old versions are retained and can still be accessed from the Client Dependency URL that was previously used (if necessary)
• Versioned composite files names are prefixed with the version number (i.e. version 2 files will be prefixed with '2_') so it's easy to figure out which files are old
• The composite file map also reflects which composite file sets are under a specific version
• Provider model extended to support 2 types of providers:
• File Registration Providers
  • Still comes with 2 providers: page header provider and a lazy loading JavaScript client based provider
• Composite File Providers:
• Comes with the standard provider: CompositeFileProcessor
• You can implement your own provider to customize the way that files are combined, compressed, minified, etc... if the standard provider isn't exactly what you are after
• Forced providers! You can now force a dependency to use a particular provider. This can be useful if you want to ensure that a particular script or stylesheet is rendered on to the page differently. For example, you may want to ensure that a script is lazy loaded (using the lazy load provider) but the rest are rendered in the page header.
• Utility methods added to the ClientDependencyLoader for more dynamic implementations
• A test website is included in the release which doubles as documentation, it includes:
  • Standard page header provider example
  • Forced providers example
  • Lazy load provider example
  • Dynamically registering dependencies in your code behind
  • Registering dependencies with attributes and via aspx controls

Things //TODO:

I’ve finished off versioning so at least i can cross that off from the previous list. But there’s still more to do:

• Implement functionality for jQuery CDN
• This will be a new control/attribute to easily include jQuery in your project
• You will have the option to select which CDN you want to use (Microsoft or Google), or you can supply an address (like your own CDN/web server)
• Though this framework will be included in Umbraco 4.1, we’ll be leaving this functionality out of the Umbraco build as we realize that there are quite a few installs that operate behind a firewall that won’t have access to the CDN.
• Implement skeleton for Microsoft AJAX 4 CDN
• Again, this will be another new control/attribute to easily include Microsoft’s new brand of AJAX with their CDN solution
• Add support for MVC
• Support for JS/CSS Minification with options to disable per dependency
• The reason this hasn’t been implemented yet is that I’ve found a lot of scripts/stylesheets break with minification so we need to be able to turn this on/off on a per file basis
• Some more documentation/examples in the example web application

Repository/Download

• CodePlex Home: http://clientdependency.codeplex.com
• The repository has the latest new version, the alpha release version is OLD so best to get the latest codebase from the Source Control tab!

History

I’ve been busy in the Umbraco core putting in place a new Client Dependency framework for version 4.1. I thought since this could benefit many other people/projects that I’d take it out of the Umbraco core and make it its own standalone project. Currently in Umbraco v4, there’s already a Client Dependency framework that you may have come across if you’ve decided to go deep within the core code. It was developed for Umbraco Canvas (live editing) by Ruben (and Niels I think) to be able to tag controls as being dependent on CSS/JavaScript files to be lazy loaded into the client’s browser to enable live editing of the page. I thought the idea was great and wanted to combine it with a bunch of work that we had done in the office already to make a library that everyone can use. So what does it do???

Features

Most of the features can be enabled/disabled in the configuration section. By default, they’re all enabled.

• Make your controls dependent on client files by:
  • Attributing your controls
  • Using the JSInclude or CSSInclude web controls
  • Dynamically registering them in code
• Provider Model so you can choose how you would like your JS and CSS files rendered
  • Comes with 2 providers: page header provider and a lazy loading JavaScript client based provider (the original lazy loader by Ruben… nice work!… slightly modified though)
  • You can explicitly tell the engine which provider you would like a particular script/stylesheet to be rendered out by if you require this. An example could be that you want one script in particular to be rendered in the page header, but another script to be lazy loaded.
• Combining and compressing JavaScript and CSS files
• Resolving the correct URL paths in CSS files while they are being combined so you don't have to worry about this
• Combining external JS and CSS files
• OutputCaching of the combined/compressed composite files
• Saving of the combined/compressed composite files for increased performance when applications restart or when the Cache expires (persistent compression/combination)
• Creation of an XML file map to tell you which saved composite files are for which real files
• Easily clearing the cache
• Tagging client files with priorites
• Tagging client files with path names so you don't have to worry about moving files around in your project, worrying about absolute vs. relative paths, or running your application in a virtual folder

This library isn’t the answer to all of your compression needs, but it is a good start or addition to something your already using. Most other compression libraries out there are module based which can do page compression, script/css compression/combination, etc… and are all a really good idea. The compression/combination part of this library is just a really good bonus on top of what it is actually made for which is making your controls dependent on client files without worrying about duplication and having full control over how you want them rendered in your page (i.e. Provider model)

Umbraco Usage

Because there are so many controls in Umbraco and so many client files, its very difficult to keep track of what has already been included in pages, other controls, etc… This library is now part of Umbraco 4.1 codebase and all controls are now using it. There was a lot of hard coding paths to either /umbraco_client or /umbraco folders which is one of the reasons Umbraco won’t run in a virtual folder in IIS. This library solves the hard coded path issue.

What this means for package developers is that they don’t have to worry about whether or not jquery, or other JS/CSS files have been included in the page, they can simply add a client dependency to their controls.

Easier Team Development

If you’re working in a team locally in your office or one that spans between different office, this implementation makes things a whole lot easier for developing controls.

Things //TODO:

• Need to add versioning
  • This will remove old versioned persistent files saved under any older version
  • Easier to deploy since right now you would need to remove the persisted files to remove the cache
• Add support for MVC
  • This should be pretty darn easy i think
• Adding some more providers (i.e. ScriptManager provider, etc…)
• Documentation

Config

<clientDependency isDebugMode="false">
  <fileRegistration defaultProvider="PageHeaderProvider"
    fileDependencyExtensions="js,css"
    enableCompositeFiles="true">
        <providers>
            <add name="PageHeaderProvider" 
                type="ClientDependency.Core.FileRegistration.Providers.PageHeaderProvider, ClientDependency.Core" />
            <add name="LazyLoadProvider" 
                type="ClientDependency.Core.FileRegistration.Providers.LazyLoadProvider, ClientDependency.Core" />
        </providers>
    </fileRegistration>
    <compositeFiles defaultProvider="CompositeFileProcessor" 										
        compositeFilePath="~/App_Data/ClientDependency"
        compositeFileHandlerPath="DependencyHandler.axd">
          <providers>
            <add name="CompositeFileProcessor" 
                type="ClientDependency.Core.CompositeFiles.Providers.CompositeFileProcessingProvider, ClientDependency.Core" />
          </providers>
    </compositeFiles>
</clientDependency>

Includes/Usage

Implementation is pretty simple…

• You need a ClientDependencyLoader to do the loading, only one of these can exist on the request (just like the ScriptManager in ASP.Net)
• You can use CssInclude and JsInclude controls in your User Controls/Pages, etc… to declare that a CSS or JS file is required OR
• You can use the ClientDependencyAttribute to attribute your composite control classes OR
• You can programmatically add a dependency by using the ClientDependencyLoader’s methods (there’s a few of these overloaded methods):

  • ClientDependencyLoader.Instance.RegisterDependency("Content.css", 
                   "Styles", 
                   ClientDependencyType.Css);

Recently we had a client who wanted to be able to preview content before they were publishing it live with Umbraco. Because we’d made some major modifications to the way the content was rendered we were unable to use the standard Umbraco preview since we weren’t using any of the <umbraco:item /> tags. So this posed a problem, how were we going to have the preview working?

We decided that we were going to have to have a content entry server, from here they could enter their content, publish it and view it, but how were we then to get it to the live site? The logical answer is that have a periodic push of the content entry servers database across to live, but that’s not ideal and it is a pretty nasty idea.

To add another level of complexity on top of the system the site has user generated content, this content would obviously be entered by site visitors and it would only be on the live site, not the staging site.

Hmm…

Then Shannon reminded me of a conversation which we had when we were in Denmark at CodeGarden 09, someone had suggested that you could use Red Gate’s SQL Data Compare to push the data across.
So I sat down with two copies of the database, and decided to work out what would be needed to achieve this. Essentially you need to reseed Umbraco so that when you do changes on one environment it can easily be spotted and resolved by Red Gate.

The following is the list of tables which you need to reseed:

• cmsContent
• cmsContentVersion
• cmsDocument
  
• cmsPropertyData
• umbracoNode

Microsoft SQL Management Studio will be able to generate reseed scripts for these tables which will handle the data migration and everything.

With this set up it opens an interesting idea which we plan to trial, having every environment seeded differently from dev onwards and using Red Gate to migrate from one to the next.

Things to keep in mind:

If it’s likely that there will be content created/ edited on both environments make sure that you put the primary key seed to be greatly spaced. For this site we reseeded the content entry environment with a start identity of 500,000. This left a good sized buffer in the cmsPropertyData table which is the table that expands the most.

If you wanted to be able to sync across multiple environments you could do:

• Dev – primary key index starting at 1
• Content Entry – primary key index starting at 500,000
• Live – primary key index starting at 1,000,000

If you want to sync more than just content (eg – Macros, Document Types, etc) you’ll have to reseed their appropriate tables too.

You still need to manually copy the Media folder across environments still, as those files aren’t stored in the database.

Well it's my first week at The FARM (who is now an Umbraco Solution Provider, we're the first in Australia!) I got to look at a bug which has been floating around for a while and no one could consistently replicate it or work out the problem.

To summarize the bug, some of the images which the client was uploading into the Umbraco Media section, then linking into the Umbraco WYSIWYG editor were being shown as broken images.
But only some images this was happening for, and we weren't quite sure which images were causing the problem and when we'd test with images they'd be fine.

So we had the client show us how to do it, in front of us and then we could dig into it a bit more, and while doing so I found something unexpected.
The problem was being caused by the image havine a file name like: MyImage_100x50.png, but the WYSIWYG editor would show MyImage.png as the URL. This obviously isn't right, so something was changing the image.

While digging into the TinyMCE code I found out that when it displays images it does a check for the image width & height in the image name, and removes it.

What... the... hell?! I'm looking at this code and I'm confused as anything about what's going on, I mean, why is it re-writing my image URL?
Oddly enough though, the image worked correctly on the published site so it was even more confusing!

After a quick email to the Umbraco core team I got a response from Niels stating that this code is meant to be there, and doing exactly what it was doing.
It turns out that when you go about resizing an image within TinyMCE itself Umbraco will then postfix the new dimensions into the URL in WidthxHeight. But since this isn't the real image URL it has to later strip it out.

So remember kids, don't put the image dimensions into the filename in Umbraco!