CYCLOMEDIA

Cyclomedia.co.uk - always believing that the chef should taste his own soup - has been converted to a bleeding edge Chan 0.9 build. Obviously work is not nearly finished, specifically in matching the HTML5 form validation sensibilities with Chan's own but some of the experience will be helpful to future developments. By far the oddest sensation was found when converting a few things to use the new MVC-ish square bracket notation. For example, whilst previously to use one of Chan's built in Icons you had to create an Image control and assign it's Path property like this:

<Chan:Image runat="server" Path="[Icon.Link]" />
	

... probably creating a whole load of ASP.Net reflection and memory overhead on the server in the process ... You can now just do this:

<img src="[Icon.Link]">
	

Entering this in raw HTML and magically having a fully configured and correctly pointed path to a PNG magically pop out of the renderer is actually a little unnerving when you're not used to it! What's more fun is that the code that performs this neat trick parses the HTML in a stream as it is output to the client meaning you can stuff these square brackets nearly anywhere. This is used internally by Chan to surpass the old Region system, whenever you bind a Panel or Fragment to a region it attaches itself to the Renderer and waits until it is asked for its HTML. whereas the pre 0.9 builds had a list of regions that had to be created and pre-filled prior to rendering, creating a lot of strings floating about in RAM.

Something that attaches itself to the Renderer and swaps out square-bracketted snippets for HTML is called a Resolver and you can easily create your own - It's a public interface with just one function. So you could have a resolver that responds to "[Foo]" with "The anwser is [Bar]" and another that resolves "[Bar]" to "42". Stick "[Foo]" somewhere in your ASPX, HTML or even the Text property of a Control and the renderer won't even break a sweat; the client will see "The answer is 42" in its place.

Anyway, as you can no doubt see it doesnt LOOK much different around here, esp considering that said Chan Reference pages are still only at 0.85. The trick is to view the pages in Opera and see the HTML5 Date and Number input types automagically appear...

The proof-of-concept browser capability detection code has been pulled into Chan's development trunk. Essentially this is an xml file containing a bunch of regular expressions that are run against the User Agent string to determine what the user is, well, using. It's lightweight and aware that the user can bugger the UA up so defaults to assuming you're at least capable of full HTML4 + JS support but also allows for both Mobile (less capable) browsers and granular resolution of what Html 5 features a browser supports.

What this means in practise is that if the RegExp sees "Opera/" in the string it assumes that you have a version that can natively support the Html 5 Date Input. It then double checks the version number with 5 through 8 overriding this. This means that you would not need to update the xml file when Opera 11 comes out, unlike MS's browsercaps system which is somewhat clunky and in practise works in the opposite direction.

Anyway, i've teased you for too long, here is a screenshot of (left to right) Firefox 3 with Javascript disabled, IE8 running normally and Opera 10. Each is showing the exact same page, and each has been automatically served a different Date input. The NoScript one, one with a javascript powered date picker and a native Html 5 <input type="date">, respectively. Click to enlarge:

After about two months of heavy pondering, design and countless scribbles on A4 paper development on Chan has resumed. The next milestone involves some refactoring of the code but in the past few days the first steps went a lot smoother than expected.

This project will result in a faster rendering engine that is free from the hacks that support panel/fragment region binding that also folds in localisation and an MVC-like token model. If you used Chan's fragments or panels to render into template regions then the only change you will need to make to your code is to replace your template placeholders with square bracketed ones. i.e. replace <!--Region--> with [Region].

The essence of the changes is a reversal in the template-region rendering code. Currently you had to get hold of the Page's Template class instance and set a region string to the value you wanted to appear there. With this release you will simply impliment an ITokenResolver interface method named TokenValue and register yourself with the page itself in a Resolvers collection. The rendering code will then ask your class for its region contents and then - and this is the best bit - parse those recursively, so you can have a class that returns the path to a resourse as "/App_Fragments/some_resourse.ext" and the /App_Fragments token will get parsed out by the built in values garnered from web.config.

The MVC model will provide (very) basic built in formatting functions invoked by prefixxing a token with one or more control chars, so [& TokenName] will cause the value your TokenValue method returns to be HTML encoded, converting & to &amp; on the fly whilst [~ TokenName] will URL encode it and [~& TokenValue] will do both! There will only be a handful of these built in but again you will be able to provide your own formatters if you desire.

Finally how does this all tie into localisation? The first part is URL rewriting, you will be able to silently localise a page by linking to a sub-pathed URL. So to present example.com/Path/Page.aspx in Belgian French you'd link to example.com/fr-BE/Path/Page.aspx and witness the magic unfold. Of course you will still need to provide your own localised strings for each that appears in your page and here you will have multiple options, the simplest will be to provide a string file for your page in a subfolder, something along the lines of example.com/Path/_Page.aspx/fr-BE.locale but you will also be able to use a database too - by implimenting a Locale interface and passing that into the page too. The translated strings will appear in the ASPX (or in the output of any control or other token, remember) as simple tokens, so [MyGreetingString] will be rendered as "Hello" by default, but as "Bonjour" when the Belgian French option is enabled.