This no longer appears to work with the Infragistics templating engine. Is it possible to get an updated sample?

Hi Karl,

I'm not sure what the problem you mentioned looks like. Can you elaborate more on that?

I'm attaching a fully functional updated version of my HTML sample so you can use it as a benchmark/playground.

Cheers,
Bobby

PS: Note that the NetFlix OData service has been discontinued for public access since April 1st so I had to use Infragistics' own OData service which we use for the official samples in the Samples Browser. 

Sorry, I was having the same problem as the original poster: trying to format a "column" in a grid combo that contains a date in order to support internationalization.

Your original solution executed two methods: igFormatter and parsetToDate in order to accomplish this:

itemTemplate: ... <p>${igFormatter(parseToDate(DateModified), 'date', 'dateTime')}</p> ...

However, I believe that this was written before the Infragistics templating engine was introduced which no longer appears to support this functionality. I can get methods to execute in the {{if portion of the template, but have not found a way to use a method in the content area.

Hey Karl,

Thanks for pointing me to the problem - I really missed the application of the igFormatter in my updated sample.
You are also correct in your assessment of the ig Templating Engine: it doesn't support functions due to performance reasons. 
I believe that this is stated in somewhere the help documentation as well.

So the problem indeed becomes tricky as hell, so the solution I can give is to use a workaround.
Instead of applying the date formatting functions in the itemTemplate, simply have the date values formatted before they are displayed.
This means modifying the date values of the date property from the source data (in the igCombo's dataBound event).

Here's the code I'm using:

$('#comboIG').igCombo({
	filterExprUrlKey: null,
	filteringType: 'local',
	renderMatchItems: 'contains',
	responseDataKey: 'd.results',
	//valueKey: 'Name',
	valueKey: 'LastName',
	width: '300px',
        //itemTemplate: "<div class=\'comboItemContainer\'><div class=\'empInfo\'><span class=\'empName\'>${Name}</span><p>${BirthDate}</p></div></div>",
        itemTemplate: "<div class=\'comboItemContainer\'><div class=\'empInfo\'><span class=\'empName\'>${FirstName} ${LastName}</span><p>${BirthDate}</p></div></div>",
	inputName: 'comboIG',

	//dataSource: 'http://labs.infragistics.com/igniteui/api/employees?callback=?', // OData v.3
	dataSource: 'http://services.odata.org/Northwind/Northwind.svc/Employees?$format=json&$callback=?', // OData v.1 or v.2
	dataBound: function(evt, ui) {
		var comboData = ui.dataSource.data();
		for(var i = 0, len = comboData.length; i < len; i++)
		{
			comboData[i]["BirthDateOriginal"] = comboData[i]["BirthDate"];
			
			// Use in case your dates are returned by an ASP.NET JSON serializer. Comment the line below if you use the Infragistics Northwind OData service.
			comboData[i]["BirthDate"] = igFormatter(parseToDate(comboData[i]["BirthDate"]), 'date', 'dateTime');
		}
	}
});

Some explanations are in order:

The official NorthWind OData service still uses the v.2 URI conventions and the default ASP.NET JSON serializer so the dates it serves are still in the format "\/Date(milliseconds)\/". This is where the igFormatter and the parseTodate functions can be used in order to get the desired formatting.
However, our Samples Browser's Northwind OData service is actually ASP.NET WebAPI with OData attributes and so it adheres to version 3 of the OData standard and it uses the NewtonSoft JSON serializer. This combination of facts means that dates are served in the "dd/MM/YYYY" format which doesn't require formatting (unless you wish to format your date in a different format).
This is why I've commented out 3 lines of the code above - you can uncomment them and switch to our Samples Browser's OData service to see the differences.

Regardless of the used OData service used, I think it's a good practice to have the original value of the date property just in case. This is why I'm backing each of those values in the BirthDateOriginal property.

PS: Sorry for the temporary awful formatting of the sample code - the forum wanted to play a trick on me with that one.

Hope this helps.
-Bobby
 

Thanks for the detailed response. This got me thinking a bit and I was actually able to resolve a majority of the scenarios by formatting the data in the web server that generates the grid js since the thread that generates it is aware of the user's current culture.

There are still some edge case scenarios where the data is updated from the browser, but I believe that we can handle these in the same way.

I think it would be very beneficial if we could use the igGrid (or a subset of it) as the dropdown display portion of the combo columns (or add a new editor type that adds this support).

I know that as soon as we release, our users are going to be clamoring for the capabilities that we took away in the upgrade from ultrawebgrid, namely the abilities to resize the columns, sort the column data, and possibly filter it (although this isn't hugely important). I think that we need to have a multi-column combo dropdown solution that treats columns as first class members rather than as afterthoughts.

Karl Costenbader said:

I think it would be very beneficial if we could use the igGrid (or a subset of it) as the dropdown display portion of the combo columns (or add a new editor type that adds this support).

Karl Costenbader said:

I know that as soon as we release, our users are going to be clamoring for the capabilities that we took away in the upgrade from ultrawebgrid, namely the abilities to resize the columns, sort the column data, and possibly filter it (although this isn't hugely important).

Karl Costenbader said:

I think that we need to have a multi-column combo dropdown solution that treats columns as first class members rather than as afterthoughts.