SVN ignore pattern

by Jon Davis 11. November 2008 13:38

This isn't news, I'm posting for my own reference as I move from computer to computer frequently as the months go by.

Here's how I set up my projects to not auto-include local or junk files when adding to SVN.

With TortoiseSVN installed, in Windows Explorer (not Internet Explorer) right-click on any directory and choose TortoiseSVN -> Settings. Then under General -> Global ignore pattern, add:

thumbs.db *.user *.suo RECYCLER bin obj *.dll *.bak *.log *.~?? *.exe *.tmp *.pdb  _[Rr]e[Ss]harper* 

EDIT 5/10/2011
Here is an update for the settings including the default setting:
*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store thumbs.db *.user *.suo RECYCLER bin obj *.dll *.bak *.log *.~?? *.exe *.tmp *.pdb  _[Rr]e[Ss]harper* *.vs10x *.dbmdl

The equivalent setting in SVN is svn:ignore. 

Surprisingly, a lot of people forget thumbs.db, which is the Windows Explorer thumbnail metadata file that's hidden by default. It's amazing how annoying that beast is in a shared SVN repository.

Anybody else have other filters that should be added? 

Tags: ,

A <button> is not a button

by Jon Davis 7. November 2008 10:46

This just bit me. I always figured that a <button>text</button> tag was the same as an <input type="button" value="text" />. This is not the case, depending on the browser.

While in IE <button>text</button> is treated as <input type="button" value="text" />, in Google Chrome and I believe in FF3, <button>text</button> is treated as <input type="submit" value="text" />. Which means that if you've been using <button onclick="..">text</button> as a way to javascript-up your user interface, and you're not decorating it with a type=".." attribute, you'll get some *cough* unexpected results.

... Results like the whole form getting submitted without your programmatic permission!! Arrrgh.

So to fix that, just get used to writing up the HTML with: <button type="button" onclick="..">text</button>. It's more markup but it's the proper way. Sucks for a bit, and then life goes on. Kinda like our economy, so I keep telling myself.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


SiteCore: Is the ultimate CMS also the ultimate ASP.NET web app in general?!

by Jon Davis 5. November 2008 20:11

 Important note: Please read this article with a grain of salt and note my follow-up post.

At my previous job as a web developer at a B2C magazine publisher, the developer team I was in was looking for CMS solutions that could be piggybacked to quickly build and sell web sites for advertisers, like microsites except being scalable to support integrating e-commerce and educational content easily. For full-out magazine content, the company had been using Krang, which is a CMS written in Perl for mySql and as such was not considerable for this initiative as we were ASP.NET developers. We looked at a number of smallish CMS systems for ASP.NET -- Umbraco, Graffiti, SubSonic web starter kit, etc. Most of these were laughable as options, even Umbraco had to be shrugged off. DotNetNuke wasn't an option because it's a prefab portal, not really a CMS, and frankly it's embarrassing (read: ugly). Sharepoint wasn't even worth considering because it, too, is a portal, and such a bear and a weird mutt of poorly integrated technologies and technology designs, plus it's an installation nightmare and we didn't have the hours it takes to get the thing installed when we knew we wouldn't likely like it. We also considered CMS's using "wiki" nomenclature, psuedo-wikis if you will. But those are not appropriate for the job.

But I recently began a job transition to another magazine publisher, this one B2B, a move that was mostly coincidence but they had the same need for a CMS--though on a larger scale, i.e. for their magazine web sites, not for microsites--but had already made the decision before I was interviewed. They'd researched many, many CMS's and considered all of them but the CMS that won in their research, hands down, was one I'd never heard of called SiteCore.

SiteCore's desktop uses a XAML-to-XHTML engine called Sheer UI to create a beautiful content editor and developer user interface.

I'm not entirely sure why I hadn't heard of SiteCore, they've actually been around since ASP.NET v1.0. But I believe it probably has to do with the fact that they've apparently gone through a very large number and extent of overhauls and evolution, such that those who evaluated SiteCore even recently might not have been here now to see what sort of monumental, breathtaking system this puppy is today.

I just completed training and am now a certified SiteCore developer. But before I took the training I was completely stoked about what was coming--the opportunity to work with this software.

SiteCore v6 is built upon ASP.NET 3.5, and it is impressively respectful of maintaining an ASP.NET-oriented developer/extensible workflow. That is to say, unlike other CMS's that try to break out of the box by using IronPython scripts (like Umbraco) or odd proprietary XML markup (SharePoint's CAML) or buried in a virtual machine image with a PHP front-end (like MindTouch Deki, yuck), SiteCore allows you to extend the CMS using your choice of ASPX pages with placeholders, ASCX controls with placeholders, C# code-only web controls, and .NET-extendable XSLT templates. Everything else, from articles to data records to drop-down options to security features to workflow states, everything else is just an "item" that is just a tree node with configurable settings. From what I can tell, on the developer & administrator end there aren't a lot of .NET 3.5 features in use right now--no LINQ, for example--but that's not the point. The point is that SiteCore makes the perfect CMS core of a site that you can extend with ASP.NET 3.5 with ease and without having to shoehorn anything because SiteCore is built to be respectful of pure ASP.NET. Even the pipelines and events are configurable and extensible, as all of the pipeline stages and event handlers are declared in a huge web.config. The web.config file also exposes niceties like for the content developers, and multi-site configurations. And yes, you use Visual Studio 2008 to extend a SiteCore-based site.

And these are just the fundamental aspects of what makes this product so awesome. Wait till you see the fluff!! SiteCore exposes to content developers, editors, and designers a user interface so profoundly rich that would make the Microsoft Office Live team pee in their pants. (And being that Microsoft is no stranger to SiteCore, they being a SiteCore customer, I'm sure they did exactly that.) SiteCore uses a proprietary dialect of XAML called "Sheer UI" that it converts to XHTML+Javascript to emit a gorgeous Windows XP-like desktop with a Start menu and everything, the point of which is not to 'wow' (which it does anyway) but to provide a focused workspace of tools that can be used to access CMS content, data structures ("data templates"), workflow management, security settings, and new feature development tools.

The best part about SiteCore, which I just found out about today, is that there is a free, one-user version you can download called SiteCore Xpress and play with right now.

The funny thing is, there are really very few "bad smells" with this system. The whole thing just feels right. It was designed right. It doesn't feel awkward, kludgy, or "shortcutted" in any way. If it does smell, it has more of a new car smell than a body odor smell.

They say a picture is worth a thousand words, but then a video is worth a million.

Now, be aware, the pro versions of SiteCore don't come cheap. In my opinion, you get what you pay for because this product is just so profoundly good, it's kinda like Apple's expensive products, it offers a fixed set of functions done right and no weirdness, just goodness. Where SiteCore differs from Apple, though, is in its completeness. After sitting through 3 days of training this week I kept having to pull up my jaw because the level of detail those guys went through to cover all aspects of real CMS and yet to do it cleanly without making a mess is just .. plain .. insane. I mean, just to throw some examples out there ...

  • Tweakable URL routing
  • *Real* content versioning, with a side-by-side diff tool.
  • Extensive (i.e. unlimited) multi-language support for content (and multi-lingual content editing / development in a few different prefab languages)
  • Extensive ACL-like security on a per-content-item basis
  • Field-level security on content fields!
  • Multiple inheritence for tree items!
  • Consolidated editing and publishing environment (that can be optionally staged in isolation)
  • Configurable workflows (i.e. approval processes)
  • Application-extensible -- build your own applications for the SiteCore desktop experience (for content editors to experience) using simple .ASPX files (no Sheer UI XML required, that stuff just runs the core)
  • Per-item performance metering (i.e. in a "tooltip window", this content item takes 10ms to render)
  • On-the-fly field editing while in preview mode
  • An API fully exposing everything you need to dynamically create or access CMS data
  • A nice "developer network" web site with detailed documentation and guides
  • A security model that even lets you use Active Directory!

.. the list would just go on and on.

The best part about SiteCore, which I just found out about today, is that there is a free, one-user version you can download called SiteCore Xpress and play with right now. From what I can tell, there are no other strings attached, i.e. no logo or ad requirements and no trial period, other than it only allows for one user (administrator), can only run on one server, and isn't licensed for commercial use. [More info] Unfortunately the one other down side (and possible deal-killer, but not likely) is that the Xpress version is v5.3, not v6. But at least it's v5.3 and not v5.

From what I've learned, v5.3 was about the time when SiteCore really reached a turning point and started making big in-roads to U.S. sales. (SiteCore is apparently developed in Denmark.) v5.3 being the last product update before the very recently released (Sep '08?) v6, it's still a very good product. I didn't use v5.3, but from what I know, I believe the things that are different in v5.3 vs. v6 are:

  • v5.3 is based on .NET 3.0 / ASP.NET 2.0, not .NET 3.5 / ASP.NET 3.5.
  • v5.3 has a proprietary thing called "masters", which were dropped in v6. In v5.3, new items had to be instantiated with templates+masters, but in v6 only templates are required.
  • The security subsystem might've been overhauled or tweaked out, such as its newly revised configuration UI.
  • v5.3 had huge performance improvements over previous versions. v6 probably has huge performance improvements on top of those, particularly as the core now takes advantage of ASP.NET 3.5 (if indeed it does, I don't know)
  • A ridiculous bug was fixed in v6 where in v5.3 cached content would process the layout anyway before returning the cached version (duh) which rumor is SiteCore isn't owning up to fix in v5.x.
  • v6 has a slick optional Page Editor which is basically a preview of the actual page (with formatting) but with inline editable regions that actually edit the CMS items on the fly.
  • v6 has a new validation component (to slap your content editors around a bit with a fish)
  • v6 has a new Grid Designer that's a nice addition but really isn't necessary

There's a review on v6 over here:

Anyway, this isn't a sales pitch as I'm just a new user, not a business partner (or at least, not yet! *grin*), but it's something I wanted to share. I love cool developer technology, particularly for .NET, and above all ASP.NET solutions I've seen on the market so far, open source or commercial, CMS or otherwise, I think SiteCore v6 sets the bar for all web applications to try to measure up to. Literally. And if you don't believe me, go download SiteCore Xpress and see for yourself.

kick it on

Currently rated 5.0 by 4 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Cool Tools | Web Development

Silverlight Still Needs 3D and Drawing API

by Jon Davis 4. November 2008 07:12

I'm gonna make this short and sweet. [EDIT: Or I thought I would.] I complained a year or so ago that the Silverlight roadmap needs to include 3D support, ideally with hardware acceleration (such as with OpenGL) and a drawing API that doesn't force you to use XAML semantics or canvas controls or other such things. More specifically, I suggested a rastarization API.

I said these things because I've seen people clamoring for such things for a long time in online entertainment and online utilities, but not from Microsoft, rather from Java applets and, more recently, Flash.

Microsoft's responses seemed to be, "Ahh pooh pooh!! What is the bUsINess nEEd?" and, "It's haaaawwrrrd!!" The latter being in relation to minimizing the codebase.

Seems Adobe was listening, though. Flash 10 adds these new features as part of the core feature set.
  • 3D effects and support. (I don't think it is OpenGL-accelerated, but at least it's there and the software renderer performs well.)
  • Enhanced drawing API ("Developers can tweak parts of curves, change styling, replace parts, and use custom filters and effects, delivering improved throughput, creative control, and greater productivity. Enhancements to the Drawing API add the z dimension, real perspective, textured meshes in 3D space, a retained graphics model, read/write rendering, and triangle drawing with UV coordinates, while adding memory and improving performance.")
  • Enhanced 2D hardware acceleration; "to paint SWF files into the browser and accelerate compositing calculations of bitmaps, filters, blend modes, and video overlays faster than would be performed in software".

Adobe's not resting on Macromedia's laurels. Silverlight 2 has some hard core competition here. Let's see if Microsoft makes the mistake of resting on Silverlight 2's laurels.

Now I'm not a Silverlight expert (still), I've had some exposure to Silverlight and have shared some light and simple blog posts but nothing special. So I might be unaware of some drawing APIs that were actually made available since my rant. I know that some real-time rasterization is possible, as is proven by Quake for Silverlight [2]. But I'm not persuaded that this Quake for Silverlight is properly optimized. In fact, I'm still scratching my head as to how it was pulled off.

Personally I'd love to see it if Silverlight and XNA consolidated agendas, although I know for certain that technically that's an impossibility (XNA is significantly platform-oriented). Microsoft needs to pay attention to Unity 3D. Unity 3D has an XNA-like runtime (full 3D support), games built with it are written in C#, and they can deploy to a web browser plug-in just like Silverlight 2, even with support for both Mac and Windows. One might say, "Why not just use Unity?" I would. Unity 3D, requiring a Mac for development, is one of the two reasons (it and the iPhone) why I bought a Mac Mini and even considered abandoning Windows. For that matter, I suppose I have abandoned Windows in a sense; for the last few months I've been using my Mac rather than Windows for my free time. But I've come to realize that I've put all my investments into Microsoft tools, and I don't want to keep spending any more money on non-Microsoft tools when I already have my hands full trying to keep up with the Microsoft tools evolution.

So in the end I wind up with being grateful for great games published by people who use a Mac, and enjoy my iPhone, but I can't do anything like any of those because I'm too distracted with Microsoft tech "evolution", the Zune doesn't have a phone, Windows Mobile doesn't have decent UI standards (where iPhone sets the bar), and for web-based games and 3D presentations Silverlight isn't up to par.

At least I have other things to think about and keep me distracted from these distractions. Like non-game technologies like ASP.NET. *sigh*

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

ASP.NET AJAX 4.0: Microsoft did it! They married the DOM and client-driven data!

by Jon Davis 3. November 2008 01:03

For over a year I've been going through a discovery process, with one pet project after another, of how it might be possible to glue Javascript objects and DOM objects together and keep them synchronized with a server in two-way data binding. And, to do it in a way that was elegant, readable, terse, trivial, and blatantly obvious and sensible. I usually failed to see this as my actual objective--I sought to find solutions to more specific problems whereby this would be the ultimate ideal.

A long while back, I came up with a script library I called Sprinkle. I created a domain name for it, I mentioned it to, and they featured an article on it. Somehow, Sprinkle disappeared and was forgotten (an oversight on my part) and no longer points anywhere.

But what Sprinkle did was quite simple. It allowed you to put src="..." on any DOM element, within reason, particularly <div>'s for HTML injection and <input>'s for default values populated from URL GETs. Then I sought to make it XHTML-compliant by using the DTD extensions spec whereby I was allowed to add my own attributes (like 'src=..') to existing declared elements (like <div>). Problem was, the browsers generated junk characters at the top of the page when I did that, so I had to use script to strip off the junk characters. The whole thing became a mess, for one simple lightweight proof of concept, and I hadn't even begun to tinker with advanced HTML and 2-way binding.

At one point a co-worker and I created a client-side MVC framework where we ended up creating DOM object assignments to "client controls" that would effectively be able to manipulate their associated DOM objects as though they were properties (which indeed they were). Nothing special in itself but it was another example of where we were marrying HTML and script. Ultimately my co-worker did most of the implementation work on that. I helped do a lot of architectural design of it, but he pointed out a lot of issues we had to work through such as dealing with composite ASP.NET server controls that defined our own client control--ClientID issues, for example, in a tree of control containers, one control nested after another.

And in my previous post I brought the whole matter up again and pondered even simple one-way data binding from scratch all over again. In the end I figured (and noted) phooey, just use client-side templates, jQuery, and JSON web services. You still, however, and up with a lot of manual work in some ways.

Anyway, the Web Forms dependency in ASP.NET AJAX made ASP.NET AJAX a complete turn-off to me all this time. I think my previous post pretty well documents why Web Forms is worth hating, most notably the evil <head runat="server"> and <form runat="server"> tags and how they completely mess everything up in a client-oriented web app.

While I reserve room for skepticism, ASP.NET 4.0 makes some promises in favor of lightweight view templates to such an extent that I'm raising my eyebrows and thinking it's worth blogging about. I'm not sure where I was back in July or so when it was announced but the new 4.0 platform promises a whole new approach to building web apps for the client. With the new ASP.NET 4.0 client templates [2], XHTML is cleanly extended using XML namespaces, and databinding and HTML templating is performed using DOM API abstractions (and jQuery) rather than server-side templating logic. What this will mean in the practical sense is yet to be proven but right now I'm thinking, holy cow. The panacea I just spoke of in my previous post has finally arrived, I think.

But let's not get ahead of ourselves. Fortunately, the proposed new ways of doing things the ASP.NET AJAX way are preview downloadable and the downloads already fetchable. We should play with this thing and provide feedback.

More info, and proof that I was a little late to the party, is at:

.. and officially here:

kick it on

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Web Development


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  August 2020  >>

View posts in large calendar