Tales from the Evil Empire

Why do we still have this stupid NumLock key on modern keyboards? Who still uses it with all of the unlocked keys duplicated about half a centimeter to the left? Hello? Keyboard designers? Please get rid of it now. Everybody hates seeing the cursor go crazy when all they wanted to do was to type a number.

Now, the people who design keyboards at Microsoft have recently come up with a new way to torture us: the F Lock key. They've decided that we needed new fixed function keys for common tasks such as save or print. This is all very well and I'm sure that having access to these functions with just one keystroke and without having to know complex ctrl key combinations is very useful to disabled persons. But why did they have to put these on our function keys?? Just add new keys, but don't replace useful keys that we're used to. Of course, the new key meanings are on by default and you need to hit F Lock to restore the old F keys. And naturally, every time you reboot, you have to hit it again.

 

Die, F Lock, die!

 

Actually, why not make these lock keys real switches if you really want to keep them? After all, they're a matter of personal preference that you just want to set once and forget about. So they could be real switches that you can't accidentally hit. That would be so much better, and it would get rid of the stupid problem that wireless keyboards have which is that they can't display the status of these keys for power consumption reasons.

Well, in fact, they could also be software settings in the keyboard drivers for all I know.

 

Finally, what's with the PrtScn key? Whenever I want to do a screen copy, I have to figure out some strange combination of F Lock, Ctrl, Alt and Shift to get the right result. And what does SysRq mean? Does any application still react to ScrLk?

 

Last minute: To get your F keys back, try this: http://www.mvps.org/jtsang/flock.html

If you've used the beta version of ASP.NET 2.0 a little, the Menu and TreeView controls in particular, you may have noticed that the datasources they consume are different from those that GridView or FormView use. But of course, Menu and TreeView have to use hierarchical data sources, whereas other controls use tabular data sources.

Tabular data sources that you get out of the box are mainly SqlDataSource and ObjectDataSource. Of course, you can also build your own data source (more on this in later posts). The nice thing is that with ObjectDataSource, you can potentially get data from any data store.

Now, for hierarchical data sources, you've got XmlDataSource and you've got SiteMapDataSource, and... and that's it. So if you want to populate a Menu or TreeView from a database, you'll pretty much have to do it from code.

Enter CompositeHierarchicalDataSource... This control I've developed on my free time (which is mainly composed of an aggregation of my serious work's compilation time) composes several tabular data sources into one hierarchical data source using relations.

Here's a simple page that displays a menu that takes its data from a composition of one ObjectDataSource and two AccessDataSources:

The nice thing is that you can in principle use any tabular data source to build your hierarchical data source. In principle only: this is still a proof of concept and is currently limited to SqlDataSources, ObjectDataSources whose views return DataViews, and datasources whose views implement ITabularDataSourceView. Another problem it currently has is that it loads all of the data at one time. It would be nice to have lazy loading for populate on demand TreeView scenarios.

 

It's shared source, so you're free to use and modify the code as you wish. Enjoy!

 

In future posts, I'll explain how it works in details, which should make a nice tutorial on how to develop your own hierarchical data source (hint of other missing data sources: LdapDataSource, FileSystemDataSource).

 

The GotDotNet CodePlex workspace for this data source can be found here:

Robin Debreuil has a great post about how the world would be a better place if we had four fingers like the Simpsons (or virtually any cartoon characters). He doesn't say anything about the yellow color or the rubbery hair, but it would sure look cool too.

His article is amazingly well documented and thought through. You can see that this guy has been thinking about building a new numbering system for years. Very impressive. And very geeky too, in a hilarious kind of way.

Unfortunately, his proposition for easier arithmetics has even less of a chance to be widely adopted as, say, the US has to adopt the hugely superior metric system or Swatch has to impose its "internet time".

So it is a total waste of energy, totally useless, impressively time-consuming and funny at the same time.

And thus highly recommended reading.

 

A few things worth noting and objections, though:

- I would actually have loved a numeric system where 4233 sounds like "butthole sniff sniff". How boring would the solar system be if we didn't have Uranus?

- A complete tutorial with exercises and a diploma at the end would be great (there are exercises at the end of the paper, but that's not enough: I want to learn)

- As has been noted in the comments, the balanced ternary system is surprisingly good too. Any chance of mixing the two for a balanced ternary bioctal system? And for a better name than that?

- I'll be saying bioctal too from now on instead of hexadecimal

- You're completely mad to spend so much time on trying to improve everyone's life whereas you should be working on your SWF/C# project

- If we forget about one of our fingers, how easier is it to count on them? Anything you can't do with the decimal system?

- Bioctal sounds like a french anti-acne medication, which is ok as geeks keep their acne quite late.

In his new and already excellent blog, Léo gives us a great diagram that details the ASP.NET 2.0 page lifecycle.

Needless to say, this is a poster you can now find in nearly all offices here in the ASP.NET team at Microsoft. Thanks for the great work, Léo!

Read it, print it, use it every day!

 

 

UPDATE: updated the links to the new locations for these resources. The poster would probably need some updating in particular where callbacks are concerned but it's still very useful.

I'm answering a post from Dimitri Glazkov here. Dimitri tracked this back to my post about UI reusability. It's probably a good idea to read his post before you go on reading this if you want to understand what this is about.

 

In an architect's ideal dreamworld, I'd say you're absolutely right, Dimitri. In the real world, though, I'd mitigate this.
After all, that's what server controls are all about: abstracting the HTML rendering and substituting higher-level abstractions for it. The controls are not ethereal entities, and they need to have some level of control over their rendering to actually work. If you want to have complete control over the rendered HTML, the only thing you can do is output it yourself, and you're back to classic ASP (or PHP). So we should probably be somewhere between complete control and pages made of only server controls.

 

I'm sure you're aware of this, but I'll say it anyways for your readers and mine who may not be as advanced as you are in ASP.NET.

 

There are a few things you can do to control the rendering of ASP.NET controls:
- Use CSS (works with any server-side web technology)
- Use styles (and in particular their CssClass property to link them to CSS) (v1)
- Use templates, which give you total control over the HTML that's rendered by some parts of the controls (usually the ones that are the most visual and are not vital for the control to actually work). Templates rule! (v1)
- Know the control set: there is a fine granularity over the control you can have over the rendering just by choosing the right control. For example, DataGrid, DataList and Repeater are similar list controls that give you more and more control over the final rendering. (v1)
- Develop your own controls, from scratch or by inheriting from an existing one. This way, you can override part or all of the rendering code. (v1)
- Use themes and skins to isolate the general presentation of the site. Themes are more or less equivalent to server-side CSS: they act at the same level of abstraction as controls, and enable to set any property (hint: even TEMPLATES) of any control, site-wide or based on a skin ID. Themes are very easy to write as they have the same syntax as a page. (v2)

 

About adapters, you're right in mentioning that there is a yet unfulfilled potential there. But it may be not in their implementation but in their very use. They may be used for something else than just device adapting. I'll try to blog on that if I have time to experiment with the concept a little more.

 

Your point about the three roles in the designer is a good one and there may be things more or less along these lines in Orcas. But if you look at it as it is currently, we're already kind of there... You have the visual design view, for designers, you have the HTML view, for what you call the prototype, and you have codebehind for the actual plumbing of the page. Yes, the first two actually act on the same thing, but at a different abstraction level.
I do not understand your third role, though: why would theme development be the role of an advanced developer? I would have given this role to the graphics designer. Well, at least, the designer can determine the general look of the page and a developer can transform that into a theme.