Extensibility | Dirty Overwriting

Basically, the article listed below was probably one of the main reasons why I`ve started these hints sharing.

Sometimes it happens, that there is no any extensibility point available, which you can apply to, but you still have functionality on your table which has to be done till morning.

Being familiar with JavaScript, you should know that this language is not strong enough to protect its methods from being overwritten. And sometimes you can use this weakness to extend existing code. “Sometimes” is quoted, because I`ve seen a lot of examples, when this approach is used not only because there are no other options, but because it is easy to use.

I would strongly suggest using this method when there are no other options available.

Another possible case is when the code is buggy and you have no time to wait for a hotfix, but you need a quick workaround. However, in this case please contact customer support, or post a comment to this article and be sure it will be handled via our developers.

The main reason why I strongly suggest avoiding this, is that it actually changes the implementation and basically overall functionality. It might not be that scary if it`s a part of deeply hidden popup view, but at the same time, if you change core control, such as format area, be ready to find broken code in a place where you didn`t even expect it to be broken.

Another reason is that it is hard to debug. I had a case when I was debugging remote environment with the similar extensions. ..and skipping allegories and epithets about pain and tears, it was very hard to find a problem.


If you still realize there is no other way, at least do it properly.

As an example, let`s create an extension which will log all your AJAX requests into console.

1\ Make sure this functionality is not implemented (Important!).

2\ Locate the method which does the things you need to extend.
In our case it is Sys.Net.WebServiceProxy.onComplete

3\ Locate the file where this method is
For us it is Ajax.ServiceProxy.js

4\ Identify a group, which needs to be extended
Open configuration file which configures editor, model, extension or core. In our case it is System.config an find the Tridion.Web.UI.Core.Ajax.WebServiceProxy group.

5\ Create an extension you will put your rules into. If you want to extend Editor resources, then create an editor extension, otherwise create a model extension.

5.1\ Implement functionality you need (following notes and warnings listed in comments below). And save it to some file.

5.2\ Create a group with your resource

5.3\ Then configure an extension group

5.4\ Register it

5.5\ Register your extension by updating System.config and adding Virtual folder.

6\ Check if it is working.

7\ Have a nice day!

One thought on “Extensibility | Dirty Overwriting

  1. UIBeardcore Post author

    There is a valid remark on Tridion.Stackexchange
    For Tridion 2011 you should extend Tridion.Web.UI.Core.Ajax group instead of Tridion.Web.UI.Core.Ajax.WebServiceProxy group mentioned above.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>