Jovan's Blog

This space is available to any ComponentArt employee to write about anything.

Browse by Tags

2
Comments
259 Views

MaskedInput Transform Intellisense

MaskedInput class's Transform property that I described in depth in a few preceding blog posts presented us with an interesting design dilemma. At first it seemed like it should be a typical enumeration property, with one value for each Transform type. However, since the architecture allowed new Transform types to be added in a number of different ways (see the previous blog posts), the enum turned out to be too stifling. For that reason, we opted for a string instead. However, we still wanted to offer some Intellisense, to give the developer a hint at the values he would most likely want to use. We did it by placing the TypeConverterAttribute on the Transform property: public sealed class MaskedInput : BaseInput { ... [TypeConverter( typeof (MaskedInputTransformConverter))] public string Transform { get {...} set {...} } ... } The implementation of MaskedInputTransformConverter is very simple: /// <summary> /// Provides Visual Studio intellisense for Transform property. /// The list of StandardValues here corresponds to the properties of client-side ComponentArt_MaskedInput_Transforms object. /// </summary> public class MaskedInputTransformConverter : TypeConverter { public string [] StandardValues = { " empty ", " CreditCard_VisaMasterCard ", " CreditCard_AmEx ", " Telephone_NorthAmerica ", " ZipCode ", " PostalCode ", " PostalCode_Australia ", " EmailAddress " }; public override StandardValuesCollection GetStandardValues(ITypeDescriptorContext context) { return new StandardValuesCollection(StandardValues); } public override bool GetStandardValuesSupported(ITypeDescriptorContext context) { return true ; } } This works really well in ASPX Intellisense, popping up the list of standard values, without forcing you to use one of them - exactly the behaviour we needed. The Intellisense also works for the Properties pane. Unfortunately it does not work in the CodeBehind files, and I don’t think there is a way to implement it there. Share this post: email it! | bookmark it! | digg it! | reddit!

Posted by: Jovan
Posted: Monday, October 27, 2008 7:06 AM
Filed under: ASP.NET AJAX, C#, Visual Studio, ComponentArt Web.UI, Input, MaskedInput
2 Comments

1
Comments
8554 Views

Client-side Date Format Localization in ASP.NET AJAX

Much buzz has already been created around new client-side localization features introduced with ASP.NET AJAX Beta 2. Most of it has focused on localized resources, which can now easily be retrieved from the server by client scripts. This makes sense - resources are arguably the most important aspect of localization. But not from a web control developer's point of view. When developing web controls, we deal with little actual content - for the most part, we are providing form for our customers' content. Having worked on ComponentArt.Web.UI Calendar control in particular, I was especially interested in localization features that deal with date and time formats. How Calendar Works Today In order for Calendar control to be customizable and culture-independent, we send information about date settings to the client, where the rendering is to take place. Examine the HTML source of a page that contains a Calendar control and you will see excerpts like these: ['AbbreviatedDayNames',['Sun','Mon','Tue','Wed','Thu','Fri','Sat']] ['AbbreviatedMonthNames',['Jan','Feb','Mar','Apr','May','Jun','Jul', 'Aug','Sep','Oct','Nov','Dec']] ['DayNames',['Sunday','Monday','Tuesday','Wednesday','Thursday', 'Friday','Saturday']] ['MonthNames',['January','February','March','April','May','June', 'July','August','September','October','November','December']] These are portions of JavaScript arrays with relevant date format information. They are put together by the Calendar control on the server, to be used by the control's rendering engine on the client. The original source of information is ASP.NET's System.Globalization namespace (unless, of course, the developer specifically instructs the Calendar control instance to use some custom date formats). It is the wealth of information in the framework that enables the Calendar to seamlessly switch between various cultures as seen in the [Globalization demo] . What ASP.NET AJAX Brings So I was really delighted to hear that as of ASP.NET AJAX Beta 2, this information is also available on the client. Only information for current culture (on the server: System.Globalization.CultureInfo.CurrentCulture ) is being propagated to the client, which makes perfect sense with - count them - 134 cultures and growing. Full documentation on this feature is not yet available, but I did a little snooping around - using the good old for/in loop mentioned in [my previous blog post] , and here's what I found out. The relevant client-side object is called Sys.CultureInfo.CurrentCulture.dateTimeFormat , and its contents for my English (Canada) culture are: AMDesignator: AM Calendar: [object Object] DateSeparator: / FirstDayOfWeek: 0 CalendarWeekRule: 0 FullDateTimePattern: dddd, MMMM dd, yyyy h:mm:ss tt LongDatePattern: dddd, MMMM dd, yyyy LongTimePattern: h:mm:ss tt MonthDayPattern: MMMM dd PMDesignator: PM RFC1123Pattern: ddd, dd MMM yyyy HH':'mm':'ss 'GMT' ShortDatePattern: M/d/yyyy ShortTimePattern: h:mm tt SortableDateTimePattern: yyyy'-'MM'-'dd'T'HH':'mm':'ss TimeSeparator: : UniversalSortableDateTimePattern: yyyy'-'MM'-'dd HH':'mm':'ss'Z' YearMonthPattern: MMMM, yyyy AbbreviatedDayNames: Sun,Mon,Tue,Wed,Thu,Fri,Sat ShortestDayNames: Su,Mo,Tu,We,Th,Fr,Sa DayNames: Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday AbbreviatedMonthNames: Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov, Dec, MonthNames: January,February,March,April,May,June,July,August, September,October,November,December, IsReadOnly: false NativeCalendarName: Gregorian Calendar AbbreviatedMonthGenitiveNames: Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep, Oct,Nov,Dec, MonthGenitiveNames: January,February,March,April,May,June,July, August,September,October,November,December, Further drilling into Sys.CultureInfo.CurrentCulture.dateTimeFormat.Calendar , we find: MinSupportedDateTime: Thu Dec 31 19:00:00 EST 99 MaxSupportedDateTime: Fri Dec 31 18:59:59 EST 9999 AlgorithmType: 1 CalendarType: 1 Eras: 1 TwoDigitYearMax: 2029 IsReadOnly: false As you can see, a lot of this information duplicates the settings propagated by the Calendar control. This is great, because I love to throw code away. In the near future, we will hopefully be able to rely on the client-side framework to provide date and time format information, and only propagate it ourselves when necessary. You can use this data for your own needs with confidence. While it is not yet documented, and has the appearance of some internal code, good folks of the ASP.NET AJAX team confirm that it will be in this same form and public, supported, and documented when ASP.NET AJAX is released. Until client-side docs are available, you can rely on the server-side documentation for DateTimeFormatInfo. Client-side object is designed to duplicate it. It feels great to see more and more of the ASP.NET framework migrate (or rather replicate itself) to the client. Soon we will all benefit from building and using a much better interweb. Share this post: email it! | bookmark it! | digg it! | reddit!