JavaScript Upgrade Strategy #5: Web Resource Organization

When designing or re-designing JavaScript Web Resources, there are a few practices that I like to follow:


One web resource per entity

Create one resource for each entity. This resource will contain JavaScript functionality related specifically to that entity.


One web resource per entity ribbon

If you have JavaScript called from Ribbon configuration (button actions, enable rules, etc.) put them into another library.  That keeps Ribbon-related code from getting “lost” in the other entity-related code you may write.


Generic or utility web resources

Anything that is not specific to an entity needs to be in a separate library. Use common sense here please.  Don’t create a large number of libraries containing only a few functions, but group them together along common functionality lines.

Maybe something like this:

  • String and data-formatting functions
  • General utility functions
  • etc.


Tool-specific resources: jQuery, JSON2, XrmSvcToolkit

Any time you have to include a tool such as jQuery or the XrmSvcToolkit, you should always create separate libraries for those unique pieces of code.

Note: I would like to advise you to NOT put the version number in the library name. Once saved, that name is read-only and if you ever upgrade, the version number will not reflect the truth.  Instead, make a library such as jQuery.js and put the version number in the library description field.


Naming Conventions

Naming of libraries is very important. I like to use the convention used by Microsoft:







You should always add the file extension to any web resource you create.  Having an extension already applied to a file will make the use of the tools we have discussed much easier for you.

  1. Great post!
    However for naming conventions, best practices from Microsoft is to use “virtual” folder strategy and use slashes in the name. This way, you can really order web resources by type.
    Personnaly, I’m using prefix_/Scripts/Ribbon/EntityName.js, prefix_/Scripts/Form/EntityName.js, prefix_/Scripts/Shared/XrmServiceToolkit.js, etc.

    This naming strategy also works better with my XrmToolBox plugin WebResourceManager with a treeview display of web resources

    • That is a great point Tanguy.

      Personally, I don’t like the embedded paths because while they work great for tools like yours, they can cause issues with other tools and can be visually confusing sometimes when reviewing the web resource list.

      I’ll try and update the article this week.

Leave a Reply