Safely navigating object hierarchies in JavaScript using prototype methods

New: Dynamically evaluate C# expressions and execute C# scripts with a single statement, from anywhere in a .NET application. Click here for more info.

Anyone who’s dealt with a deeply nested set of properties in JavaScript, whether through use of an extensive third-party JavaScript API or a custom library, has likely run into the problem of safely accessing such structures. One can of course hand-roll many ugly, hard-to-read statements like the following, adding on to the maintenance burden of the code (splitting lines as necessary for length, of course):

if (a && a.b && a.b.c && a.b.c.d && a.b.c.d.e) { doSomethingWith(a.b.c.d.e); }

The main alternative to this approach is to make such accesses within a try-catch block, but this is generally slower by at least a couple of orders of magnitude when exceptions are thrown, so not always useful in tight loops and other performance-sensitive situations. It’s also arguably an abuse of the try/catch mechanism.

Luckily, a less unsavory solution with fairly good performance can be adopted using JavaScript prototype methods. Here’s a reference implementation, and you can also try it for yourself (with timings):

// Indicates whether an object has the indicated nested subproperty, which may be specified with chained dot notation 
// or as separate string arguments.
Object.prototype.hasSubproperty = function() {
	if (arguments.length == 0 || typeof(arguments[0]) != 'string') return false;  
  var properties = arguments[0].indexOf('.') > -1 ? arguments[0].split('.') : arguments;    
  var current = this;
  for(var x = 0; x  -1 ? arguments[0].split('.') : arguments;    
  var current = this;
  for(var x = 0; x < properties.length; x++) {
  	current = current[properties[x]];
    if ((typeof current) == 'undefined') return undefined;
  }  
  return current;
};

// Gets the indicated nested subproperty, which may be specified with chained dot notation or as separate arguments.
// If the specified subproperty (or any intervening object in the hierarchy) is not found, returns undefined.
Object.prototype.getSubproperty = function() {
	if (arguments.length == 0 || typeof(arguments[0]) != 'string') return false;  
  var properties = arguments[0].indexOf('.') > -1 ? arguments[0].split('.') : arguments;    
  var current = this;
  for(var x = 0; x < properties.length; x++) {
  	current = current[properties[x]];
    if ((typeof current) == 'undefined') return undefined;
  }  
  return current;
};

// Sets the indicated nested subproperty, which may be specified with chained dot notation or as separate arguments.
// If any intervening object in the hierarchy is not found, returns false, otherwise sets the value and returns true.
Object.prototype.setSubproperty = function() {
	if (arguments.length  -1 ? arguments[0].split('.') : Array.prototype.slice.call(arguments, 0, arguments.length - 1);    
  var parent, current = this;
  for(var x = 0; x < properties.length - 1; x++) {
  	current = current[properties[x]];
    if ((typeof current) == 'undefined') return false;
  }  
  current[properties[properties.length - 1]] = arguments[arguments.length - 1];
  return true;
};

Some observations: if you run the timings, you’ll note that the try-catch method is still quite fast when exceptions are not thrown, indicating that try-catch might be workable when exceptions are expected to be truly… exceptional. Still, in any but extraordinary conditions, the performance of the prototype-method approach should be quite fast enough, avoids worst-case performance, and is cleanest overall.

Advertisements

Emulating the Java BorderLayout in CSS

In putting together a CSS framework, I wanted to duplicate the functionality of the Java BorderLayout. There’s a fair amount of (generally partially complete) info on the web about how to do this, with many of the methods having one drawback or another, e.g. needing to put the center/body child container after both sidebars if using a float-based approach. As it turns out, the CSS table layout, introduced way back in CSS 2, makes it a snap. Try the JSFiddle for yourself.

The bone-simple CSS, with compass-point naming eschewed in favor of more standard CSS names:

.borderLayout {
  display: table;  
  width: 100%
}

.borderLayout .top {
	display: table-row;
}

.borderLayout .left {
    display: table-cell;
    vertical-align: middle;
    width: 10%;
  }

.borderLayout .center {
    display: table-cell;
    vertical-align: middle;
}

.borderLayout .right {
    display: table-cell;
    vertical-align: middle;
    width: 10%;
  }
  
.borderLayout .bottom {
	display: table-row;	
}

The layout is then quite simple to use, the main charm of BorderLayout, and can be safely nested as well. Try the JSFiddle for yourself.

A C# queue package designed for high performance and ease of use

New: Dynamically evaluate C# expressions and execute C# scripts with a single statement, from anywhere in a .NET application. Click here for more info.

I’ve recently published a carefully constructed set of generic queues as part of the SharpByte project. These were all developed pursuant to the SharpByte CMS (the first of its type–more about which will be forthcoming), but are publicly released under the MIT license for any who wish to use them.

The priority queue abstract data type is similar to a regular queue, but allows each item to have a priority associated with it. For certain types of server-side programming this can be extremely useful for controlling the flow of work items. Implementations in the package include PriorityQueue and ConcurrentPriorityQueue.

The double-ended queue can be just as useful in its own way, as it can function as a queue, list (if list semantics are supported, as they are with this implementation), or stack. As such it’s one of the most useful general-purpose data structures. Implementations in the package include DoubleEndedQueue and ConcurrentDoubleEndedQueue.

Each queue in the package supports full list operations, and in fact implements IList and IList<T>. Performance has been tested and throughput on the queues under load was seen to be fast under a range of different processing conditions, including multithreading.

All queues in the package can also serve as connectors or work routers within an application, as they can have one or more outputs added, which can be any .NET collection capable of receiving items of the generic type supported by a particular queue. The semantics for this can be seen in the IQueue interface. Strategies for distribution to child queues/collections include multicasting, simple load-balancing, and round-robin distribution.

Also in the same collections package are potentially helpful odds and ends, including read-only dictionary and list collections, as well as read-only views of mutable dictionaries and lists. These are different from the read-only interfaces now supported in .NET, as they cannot be cast successfully to mutable dictionaries and lists. The CharHashSet class is an implementation of ISet for chars which generally outperforms HashSet<char>, and can be useful for certain specialized operations dealing with strings.

Some thoughts on global extension methods

New: Dynamically evaluate C# expressions and execute C# scripts with a single statement, from anywhere in a .NET application. Click here for more info.

In the past, I’ve sometimes found it useful to place some very generic extension methods in the global namespace, and/or at a visibility level corresponding to the classes extended. This can ease reuse, as the extension methods don’t require developers to take extra steps or have extra knowledge to use them; they’re just immediately available in type-ahead. Anyone who has suffered through using a namespace-happy API with multiple locations for extension methods may thank you for this approach.

As a brief example, consider the extension methods below. These mainly provide a bit of syntactic sugar for working with regular expressions, by converting what would often be multi-line calls into a single expression. The hiding of the System.Text.RegularExpressions namespace would be complete, except that in a few cases Match objects are exposed, as useful bundles of values and indices in the original string; System.Text.RegularExpressions would never need to be explicitly used even with those methods, if the var keyword were used.

using System.Collections.Generic;
using System.Text.RegularExpressions;

public static partial class StringExtensions
{
    private static MatchCollection EmptyMatchCollection = Regex.Matches("", "0");

    private static Match UnsuccessfulMatch = Regex.Match("a", "b");

    public static bool IsMatch(this string s, string pattern, bool isCompiled = false, bool ignoreCase = false)
    {
        if (s == null || pattern == null) return false;
        RegexOptions options = RegexOptions.CultureInvariant;
        if (ignoreCase)
            options |= RegexOptions.IgnoreCase;
        if (isCompiled)
            options |= RegexOptions.Compiled;
        return Regex.IsMatch(s, pattern, options);
    }

    public static int IndexOfPattern(this string s, string pattern, bool isCompiled = false, bool ignoreCase = false)
    {
        if (s == null || pattern == null) return -1;
        RegexOptions options = RegexOptions.CultureInvariant;
        if (ignoreCase)
            options |= RegexOptions.IgnoreCase;
        if (isCompiled)
            options |= RegexOptions.Compiled;
        Match match = Regex.Match(s, pattern, options);
        return match.Success ? match.Index : -1;
    }

    public static int LastIndexOfPattern(this string s, string pattern, bool isCompiled = false, bool ignoreCase = false)
    {
        if (s == null || pattern == null) return -1;
        RegexOptions options = RegexOptions.CultureInvariant | RegexOptions.RightToLeft;
        if (ignoreCase)
            options |= RegexOptions.IgnoreCase;
        if (isCompiled)
            options |= RegexOptions.Compiled;
        Match match = Regex.Match(s, pattern, options);
        return match.Success ? match.Index : -1;
    }

    public static MatchCollection Matches(this string s, string pattern, bool isCompiled = false, bool ignoreCase = false)
    {
        if (s == null || pattern == null) return EmptyMatchCollection;

        RegexOptions options = RegexOptions.CultureInvariant;
        if (ignoreCase)
            options |= RegexOptions.IgnoreCase;
        if (isCompiled)
            options |= RegexOptions.Compiled;

        return Regex.Matches(s, pattern, options);
    }

    public static IEnumerable FindAll(this string s, string pattern, bool isCompiled = false, bool ignoreCase = false)
    {
        if (s == null || pattern == null) return new List();

        RegexOptions options = RegexOptions.CultureInvariant;
        if (ignoreCase)
            options |= RegexOptions.IgnoreCase;
        if (isCompiled)
            options |= RegexOptions.Compiled;
        
        return Regex.Matches(s, pattern, options).Select(m => m.Value);
    }

    public static Match Match(this string s, string pattern, bool isCompiled = false, bool ignoreCase = false)
    {
        if (s == null || pattern == null) return UnsuccessfulMatch;

        RegexOptions options = RegexOptions.CultureInvariant;
        if (ignoreCase)
            options |= RegexOptions.IgnoreCase;
        if (isCompiled)
            options |= RegexOptions.Compiled;

        return Regex.Match(s, pattern, options);
    }

    public static Match MatchLast(this string s, string pattern, bool isCompiled = false, bool ignoreCase = false)
    {
        if (s == null || pattern == null) return UnsuccessfulMatch;

        RegexOptions options = RegexOptions.CultureInvariant | RegexOptions.RightToLeft;
        if (ignoreCase)
            options |= RegexOptions.IgnoreCase;
        if (isCompiled)
            options |= RegexOptions.Compiled;

        return Regex.Match(s, pattern, options);
    }

    public static string Find(this string s, string pattern, bool isCompiled = false, bool ignoreCase = false)
    {
        if (s == null || pattern == null) return "";

        RegexOptions options = RegexOptions.CultureInvariant;
        if (ignoreCase)
            options |= RegexOptions.IgnoreCase;
        if (isCompiled)
            options |= RegexOptions.Compiled;

        Match match = Regex.Match(s, pattern, options);
        return match.Success ? match.Value : "";
    }

    public static string FindLast(this string s, string pattern, bool isCompiled = false, bool ignoreCase = false)
    {
        if (s == null || pattern == null) return "";

        RegexOptions options = RegexOptions.CultureInvariant | RegexOptions.RightToLeft;
        if (ignoreCase)
            options |= RegexOptions.IgnoreCase;
        if (isCompiled)
            options |= RegexOptions.Compiled;
        Match match = Regex.Match(s, pattern, options);
        return match.Success ? match.Value : "";
    }

}

The MatchCollection class itself is kind of an odd duck, as it’s a useful collection that was never fully updated for use with Linq. If one makes frequent use of regular expressions it might be useful to also put a few simple Linq-enabling extension methods on MatchCollection itself; it’s up to the user whether to make them global. I leave it to the reader to implement the rest of the Linq methods as deemed useful in a particular case.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text.RegularExpressions;

public static partial class MatchCollectionExtensions
{
    public static bool Any(this MatchCollection source, Func<Match, bool> predicate)
    {
        return source.Cast<Match>().Any(predicate);
    }

    public static Match First(this MatchCollection source)
    {
        return (source == null || source.Count == 0) ? null : source[0];
    }

    public static Match First(this MatchCollection source, Func<Match, bool> predicate) {
        return source.Cast<Match>().First(predicate);
    }

    public static Match FirstOrDefault(this MatchCollection source)
    {
        return (source == null || source.Count == 0) ? null : source[0];
    }

    public static Match FirstOrDefault<T>(this MatchCollection source, Func<Match, bool> predicate)
    {
        return source.Cast<Match>().FirstOrDefault(predicate);
    }

    public static Match Last<T>(this MatchCollection source)
    {
        return (source == null || source.Count == 0) ? null : source[0];
    }

    public static Match Last(this MatchCollection source, Func<Match, bool> predicate)
    {
        return source.Cast<Match>().Last(predicate);
    }

    public static Match LastOrDefault(this MatchCollection source)
    {
        return (source == null || source.Count == 0) ? null : source[source.Count - 1];
    }

    public static Match LastOrDefault<T>(this MatchCollection source, Func<Match, bool> predicate)
    {
        return source.Cast<Match>().LastOrDefault(predicate);
    }

    public static IOrderedEnumerable<Match> OrderBy<Match, TKey>(this MatchCollection source, Func<Match, TKey> keySelector)
    {
        return source.Cast<Match>().OrderBy(keySelector);
    }

    public static IOrderedEnumerable<Match> OrderBy<Match, TKey>(this MatchCollection source, Func<Match, TKey> keySelector, IComparer<TKey> comparer)
    {
        return source.Cast<Match>().OrderBy(keySelector, comparer);
    }

    public static IOrderedEnumerable<Match> OrderByDescending<Match, TKey>(this MatchCollection source, Func<Match, TKey> keySelector)
    {
        return source.Cast<Match>().OrderByDescending(keySelector);
    }

    public static IOrderedEnumerable<Match> OrderByDescending<Match, TKey>(this MatchCollection source, Func<Match, TKey> keySelector, IComparer<TKey> comparer)
    {
        return source.Cast<Match>().OrderByDescending(keySelector, comparer);
    }

    public static IEnumerable<Match> Reverse(this MatchCollection source)
    {
        return source.Cast<Match>().Reverse();
    }

    public static IEnumerable<TResult> Select<TResult>(this MatchCollection source, Func<Match, TResult> selector)
    {
        return source.Cast<Match>().Select(selector);
    }

    public static IEnumerable<TResult> Select<TResult>(this MatchCollection source, Func<Match, int, TResult> selector)
    {
        return source.Cast<Match>().Select(selector);
    }

    public static IEnumerable<Match> Skip(this MatchCollection source, int count)
    {
        return source.Cast<Match>().Skip(count);
    }

    public static IEnumerable<Match> Take(this MatchCollection source, int count)
    {
        return source.Cast<Match>().Take(count);
    }

    public static Dictionary<TKey, Match> ToDictionary<Match, TKey>(this MatchCollection source, Func<Match, TKey> keySelector)
    {
        return source.Cast<Match>().ToDictionary(keySelector);
    }

    public static Dictionary<TKey, Match> ToDictionary<Match, TKey>(this MatchCollection source, Func<Match, TKey> keySelector, IEqualityComparer<TKey> comparer)
    {
        return source.Cast<Match>().ToDictionary(keySelector, comparer);
    }

    public static Dictionary<TKey, TElement> ToDictionary<Match, TKey, TElement>(this MatchCollection source, Func<Match, TKey> keySelector, Func<Match, TElement> elementSelector)
    {
        return source.Cast<Match>().ToDictionary(keySelector, elementSelector);
    }

    public static Dictionary<TKey, TElement> ToDictionary<Match, TKey, TElement>(this MatchCollection source, Func<Match, TKey> keySelector, Func<Match, TElement> elementSelector, IEqualityComparer<TKey> comparer)
    {
        return source.Cast<Match>().ToDictionary(keySelector, elementSelector, comparer);
    }

    public static List<Match> ToList<T>(this MatchCollection source)
    {
        return source.Cast<Match>().ToList();
    }

    public static IEnumerable<Match> Where<T>(this MatchCollection source, Func<Match, bool> predicate)
    {
        return source.Cast<Match>().Where(predicate);
    }
}

The MemoryCache class is another fundamentally useful .NET class that has a bit of a clumsy API, which can be remedied by providing facades to the clunkier methods. Very often one merely wants to set a cache duration when setting an object, and get an object of a specified type safely.

using System;
using System.Runtime.Caching;

public static partial class MemoryCacheExtensions
{
    public static void Set(this MemoryCache cache, string key, object value, long durationMilliseconds)
    {
        if (cache == null || key == null) throw new ArgumentNullException();
        else if (durationMilliseconds <= 0) return;
        else if (value == null)
            try { cache.Remove(key); } catch {}

        DateTimeOffset expiration = DateTime.Now.AddMilliseconds(durationMilliseconds);
        cache.Set(key, value, expiration);
    }

    public static T Get<T>(this MemoryCache cache, string key, T defaultValue = default(T))
    {
        object value = cache.Get(key);

        if (value == null || !(value is T))
            return defaultValue;
        else
            return (T)value;
    }
}

The common thread in these examples is that even in the .NET FCL (and CoreFX for that matter), API design is not always optimal. A primary use case for extension methods is where a developer desires to add useful functionality to an API, but without the ability to control the API itself, and this applies to .NET fundamentals as easily as anything else. When one is adding those methods to a core class, it may make sense to make the extension methods themselves as visible as the core classes so extended–and here the efficiency/usability gains of broadening visibility can be tainting in a sense, as above where the MatchCollection extensions are made global by virtue of the fact they may be returned from the result of another global extension method on the String class.

This may not be everyone’s cup of tea, and in fact I don’t tend to do this for seldom-used, specialty classes ever. The String class is obviously a different case from even MatchCollection and the like. And whenever creating extension methods, but increasing with their visibility, one should strongly consider placing them in partial, wisely named classes to avoid naming collisions in the future.

A tiny, cross-browser script to intercept third-party JavaScript injection via document.write()

Many of us have encountered third-party scripts which use document.write(), particularly for script injection. Certain older analytics scripts use this approach ({cough} {cough} {Omniture!}). If you’re stuck maintaining an older site with a projected end-of-life, you may not have the time to upgrade those old bad scripts away, especially if they’re hosted externally and dynamically generated.

Unfortunately, many of those same scripts were written without async loading in mind, and by render blocking, blocking on the DOM or CSSOM, etc. can greatly decrease performance of your site; a second-plus of unnecessary page-load time is not uncommon. The problem is so pervasive that Google finally put its metaphorical foot down, ever so lightly, by decreasing support for third-party document.write() statements; as an immediate effect of this change, certain scripts may not even be loaded on mobile, defeating the purpose of loading the scripts in the first place.

This can leave us in a pickle: how to intercept document.write() calls by these third-party scripts without disabling analytics or other functionality for which they were included in the first place, ideally while decreasing page-load times through the use of async/defer loading?

This can be done by replacing document.write with a function that intercepts attempts to inject scripts in this way, and instead adds them dynamically to the DOM, while passing through all other non-script parameters to the original document.write() function:



// 1. Moves the document.write() method, for safekeeping
document.writeText = document.write;

// 2. Assigns a new function to document.write(), to serve as a middleman
document.write = function(parameter) {
    if (!parameter) return;
	
	var scriptPattern = /<script.*?src=['|"](.*?)['|"]/;
	if (scriptPattern.test(parameter)) {
		// Get the value of the src attribute
		var srcAttribute = scriptPattern.exec(parameter)[1]; 
		// Add the script to the DOM 
		var script = document.createElement('script');
		script.src = srcAttribute;
		document.head.appendChild(script); 
	}
	else {
		document.writeText(parameter);
	}	
};

The last piece of the puzzle, if you’re also interested in decreasing page-load time with these older libraries, is to load them asynchronously. Options here would include the following:

1. Use of libraries such as postscribe , jQuery etc., to help with async-loading external scripts in general.

2. Using the async and/or defer properties directly on the script tag including a legacy library (I’m unaware as of this writing of a way to do this cleanly with cross-browser support using the DOM and avoiding use of innerHTML). This may be recommended against, as discussed further below after #3.

3. Especially in the case of a legacy script which is relatively lightweight itself but uses document.write() extensively to inject script tags, you could allow the first script to load synchronously, but use the technique above to write the script tags yourself, adding async and defer as desired. This may significantly decrease page load time, because the bulk of render-blocking script loads are avoided. To use this technique, modify the code sample to use document.writeText()–or whatever you’ve called your placeholder for the old document.write()–to emit an HTML script tag, using the regex-parsed src value and adding adding “async defer” directly.

Adobe in particular has consistently recommended against loading DTM libraries async, and this legacy can be seen stretching back to the days of the fore-mentioned Omniture, which unfortunately does use document.write() extensively to load other scripts from dynamically generated code. Thus a working approach to get at least some such scripts loaded asynchronously, while avoiding page flicker, can be to leave the script-loading legacy script in place as-is, but intercept its calls to document.write().

Global.asax, Keeping the Magic Alive

In my efforts to retrofit an old Sitecore Web Forms application for caching which is safe for use with postback, etc. in an elegant way, I needed to review the full set of “magic” methods available in the Global.asax application file, which ASP.NET wires up at runtime.

As a reminder, make sure that you’ve included a script runat=”server” tag enclosing your code–you may have to restore this if deleted from, or never added to, an empty file. Confusion abounds on the web as to whether Global.asax works with ASP.NET MVC (it does), primarily because of this missing script tag.

The application- and session-specific event methods are:

Application_Start
Application_End
Application_Error
Session_Start
Session_End

The request-specific events are:

Application_BeginRequest
Application_AuthenticateRequest
Application_AuthorizeRequest
Application_ResolveRequestCache
Application_AcquireRequestState
Application_PreRequestHandlerExecute
Application_PreSendRequestHeaders
Application_PreSendRequestContent
Application_PostRequestHandlerExecute
Application_ReleaseRequestState
Application_UpdateRequestCache
Application_EndRequest

Sources:
https://web.archive.org/web/20071223170129/http://articles.techrepublic.com.com/5100-10878_11-5771721.html
http://sandblogaspnet.blogspot.com/2008/03/methods-in-globalasax.html

An Aspect-Oriented Programming (AOP) Approach to Logging

New: Dynamically evaluate C# expressions and execute C# scripts with a single statement, from anywhere in a .NET application. Click here for more info.

Logging is a topic near and dear to my heart, having in an earlier version of .NET created a logging package tuned for high performance and used many others since. Today, with multiple popular offerings available to the .NET developer with different strengths and weaknesses (NLog, Log4Net, Serilog et al.) it’s not unusual to see adapters in local codebases to allow configuration and use of different packages as desired. This is actually a practice I recommend, to decouple local APIs from the implementation of a solution to a common and cross-cutting concern.

This naturally leads to thoughts of simplifying access in one’s API to the logging code. Aspect-oriented logging has in the past included attribute-based approaches, such as in PostSharp. But what if one hasn’t adopted such a library, or would like to log statements from code inside existing methods?

Suppose that one has logging classes presumably configured using some IoC implementation, and wants to decorate an API with logging functionality without undue clutter. One can use C# extension methods and weak references together with a marker interface to achieve the desired effect. Here are the steps:

1. Create an interface with which to decorate classes that will generate log information. (In the linked code sample, see the ILogSource interface.)

2. Add extensions to the log-source interface to support logging messages and/or events, corresponding with the desired use of the logging API, and to get and set a logger using a weak reference. (In the linked code sample, see the ILogSourceExtensions static class, stored with ILogSource in ILogSource.cs).

3. Decorate any desired class with logging functionality by implementing the marker interface, and configuring it with a logger as desired, then calling its logging methods within its other code. (See the code sample for more.)

This approach still allows an adapter to a target logging API to be used, and run-time configuration of the implementation as desired. It merely provides syntactic sugar to avoid littering your API with logging substructure in base classes and the like, by reducing the necessary plumbing to a single interface marked on the logging client class. The overhead of looking up the weak-referenced logger turns out to be minimal, at several nanoseconds per call. I’m still thinking through how best to wire this together with injection; constructor injection seems to obviously be out of the question.

Cure YSOD in the Sitecore Template Inheritance Tab

New: Dynamically evaluate C# expressions and execute C# scripts with a single statement, from anywhere in a Sitecore or .NET application. Click here for more info.

I recently encountered a Yellow Screen O’ Death (YSOD) error when attempting to use the template inheritance tab while viewing a template in the Sitecore Content Editor. As it turned out, the culprit was a template field with a blank type. To find such fields, run the following query to find the fields, then set their types:

/sitecore/templates/User Defined//*[@@TemplateKey = 'template field' and @Type='']

How to use the File Explorer and XPath Builder in Sitecore 8.1

New: Dynamically evaluate C# expressions and execute C# scripts with a single statement, from anywhere in a .NET application. Click here for more info.

Later versions of Sitecore don’t provide an easy way to launch the Sitecore File Explorer and XPath Builder from the web, but they’re still there. In order to use them, go directly to the following URLs on your instance, and enjoy.

/sitecore/shell/default.aspx?xmlcontrol=FileExplorer
/sitecore/shell/default.aspx?xmlcontrol=IDE