U4-3027 - Document Type alias auto-generates with first letter capitalized

Created by Morgan Klipp 02 Oct 2013, 19:55:03 Updated by Stephan 30 Apr 2014, 10:42:13

Relates to: U4-4747

I've noticed for quite a few releases now that when I create a new Document Type, the alias auto-generates with a capitalized first letter (if the name I give it has an upper-case first letter). I know that this shouldn't be the case (no pun intended), because when I click on the input area for the alias the background turns red. Any other posts on this issue? Thank you!


Stephan 02 Oct 2013, 20:19:06

What version of Umbraco? What exact name are you using for your document type?

Aliases can be upper or lower case, it does not really matter.

Morgan Klipp 02 Oct 2013, 20:41:48

v6.1.5 "Callout Container" is the name of the latest document type I've created (auto-generates "CalloutContainer"), but all document types I create with the first letter being upper-case will have the first letter as uppercase in the Alias. When I click in the text-box for the alias, the background turns red until I make the first letter lower-case. Which leads me to believe that it could cause an issue somewhere.

Stephan 23 Apr 2014, 08:28:46

With 6.2 and 7.1 there is no "first letter casing" by default. If you create "Callout Container" the proposed alias is "CalloutContainer", if you create "callout Container" the proposed alias is "calloutContainer". It is always possible to change it once the content type has been created. Both aliases work fine.

The box does not turn red if the first letter is upper-case.

So, the question I guess is, is it OK like that or should we make a choice and ensure that the proposed alias always begins with an upper- (or lower-) case?

Stephan 23 Apr 2014, 08:41:09

Vote: when I create a document type with a given name, should the first letter of the proposed alias be:

  1. upper-case
  2. lower-case
  3. unchanged wrt name ?

Lars-Erik Aabech 23 Apr 2014, 08:45:46

c As far as I can understand, the alias of types has no technical implications what so ever. It's mostly just shorter and easier to type.
However, usage of it via the APIs should really be case insensitive if flexibility about it is increased.

Mads Krohn 23 Apr 2014, 08:46:42

IIRC the best practice approach have always been uppercasing for document types (MyDocumentType) and lower casing for properties (myProperty). I Believe it has been more or less enforced in earlier versions. In my opinion it doesn't matter, but I will probably still adhere to the old ways :)

Jesper Hauge 23 Apr 2014, 08:49:10

I'd vote for unchanged from user input when created (and case sensitive when used in code - but that's just me being a grumpy old no-dynamic-languages-in-my-code kind-a-guy)

Lars-Erik Aabech 23 Apr 2014, 08:56:22

@Jesper, I use typed models anyway, so it doesn't matter. The alias is just for querying, and SQL server (at least) is mostly case insensitive. ;)

Dirk De Grave 23 Apr 2014, 08:56:40

+1 on what Jesper says

Morten Christensen 23 Apr 2014, 09:07:00

+1 on what grumpy old man said ;-)

James South 23 Apr 2014, 09:22:57

Standardise it across the board and then strictly enforce that.

Code should be maintainable, I don't want to have to pick up someone elses work and spend too much time figuring out what they were doing based upon whatever took their fancy that day.

I don't want have to guess the property casing when looping through properties and looking the values up using IPublishedContent.GetPropertyValue()

Personally I would remove diacritics, use Pascal casing, and remove whitespace thus following the C# language naming specification for properties and classes.

To be honest I'm not even sure why they are editable.

Stephan 23 Apr 2014, 09:30:51

@James - GetPropertyValue(alias) is already case-insensitive anyway. And we do remove anything that's not ASCII and whitespaces, so an alias should be a valid C# name (precisely because we want to be able to use it as a token in JavaScript of C# code).

This is just about the casing, where enforcing anything triggers riots in the name of backward compatibility...

James South 23 Apr 2014, 09:49:14

@Stephen Everyday is a schoolday! :) That I didn't know. In that case then can you not just enforce the casing client side for any new properties? It should at least be predictable.

Douglas Robar 23 Apr 2014, 10:09:53

I like consistency and predictability. If it doesn't matter what casing is used then doctype properties, macros, etc shouldn't follow any pattern either. I don't think anyone would recommend getting rid of first-letter capitalization policies everywhere in Umbraco. Thus I recommend that document type aliases follow a predictable pattern as well. Indeed, this used to be the situation and was somehow lost in v7 (and perhaps recent versions of v6 though I haven't tested to confirm when this was lost).

Umbraco typically uses camelCase for aliases because... it always has. Razor prefers PascalCase and that can cause problems/confusion for the many who don't use strongly typed models and intellisense to write their code. What I've found and recommend to students is that, in Razor, you ALWAYS capitalize the first letter after a dot/full-stop/period no matter what the alias capitalization is in Umbraco.

For instance, you would use @CurrentPage.BodyText even though the property alias is bodyText.

The reason is that sometimes the capitalization makes a difference in Razor. When it does, it will always want the capital first letter. When it doesn't matter, capitalizing the first letter gives no problems. So rather than having to learn when you do/don't have to use a capital first letter after the 'dot' I make it a habit to always capitalize the first letter in razor. Just like when writing a paragraph of text, after a sentence you use a dot/full-stop/period and the next letter will be capitalized. Easy to remember.

But inside Umbraco itself aliases have been camelCase and should remain so. Document Types can have either camelCase or PascalCase and should be enforced for newly created document types, leaving existing aliases as-is for backward compatibility and upgrades.

The choice of camelCase or PascalCase should be based on two decision points:

  1. Razor should still work with the 'capital after a period' policy, otherwise we're doing a disservice to users who don't use Visual Studio. Using code such as @CurrentPage.TextPages should work. If this requires PascalCase of the document type alias then the decision is made right there.

  2. If #1 works with document type aliases with either camelCase or PascalCase then the choice should be made based on the convention used in earlier versions of Umbraco (4.1 or 4.5 I would guess, from memory).

  3. If #2 isn't definitive then I don't really care which. I could argue that camelCase is the defacto standard for aliases in Umbraco and we should be consistent in that, rather than (seemingly) haphazard. On the other hand, using PascalCase for docTypes and camelCase for doctype properties is an acceptable standard as well.

Lars-Erik Aabech 23 Apr 2014, 10:37:55

People are free to use convetions. Convetions are good.

However I don't think Umbraco should force the convetions.

Microsoft recommends pascal casing of public fields, properties and methods and camel casing for privates. But the IDE and compiler won't change stuff or throw errors at you if you choose your own convesions.

The fact that queries and methods like GetPropertyValue are case insensitive should be reflected in the validation.

Stephan 23 Apr 2014, 10:43:19

Bringing fuel to the discussion... Doug, surprised you don't mention XSLT ;-) In XSLT/XPATH the element matching is case-sensitive, so "/descendantsnewsItem" is not equivalent to "/descendantsNewsItem". And the element name ''is'' the alias. For backward compatibility's sake we have to support whatever casing users have decided to use (we can't force-change their aliases).

Self-trolling: sure but we should get rid of XSLT support now. OK, I've done it, you don't have to.


  • When you create a document type, by default we propose a true PascalCasing alias, but you can always edit it later on, provided that it remains a valid alias (no exotic chars, etc).
  • When you create a property type, by default we propose a true camelCasing alias, but you can always edit it later on, provided that etc.
  • GetPropertyValue is case-insensitive. In Razor the proper syntax is model.PascalCasing. In XSLT you'd have to do "/descendants::NewsItem/datePublished" unless you edit the aliases.

Why do I mention "true" Pascal/camel casing? Well... because legacy is not "true". Eg the string "foo bAr nIL" would be pascal-cased as "FooBArNIL". Nice, eh? And we still support that in 6 and 7 at the moment, and I'd really like to get rid of it.

One more thing: we'll probably have a similar question for templates. See U4-2616.

Lars-Erik Aabech 23 Apr 2014, 10:47:30

Sounds good!

Douglas Robar 23 Apr 2014, 10:52:03

@zpqrtbnk Haha, I thought about mentioning XSLT/XPATH but decided to let that go; it can't now be considered mainstream enough for it to be a basis for decision, except for backward compatibility. Hence the desire to NOT change any existing aliases on a site. XSLT will eventually become so little used that it will naturally become deprecated and eventually obsolete. Much as I love XSLT I don't use it on client sites because the people who will maintain those sites long-term don't know XSLT. I have to cater to what people actually know.

Your proposed solution works for me.

Mads Krohn 23 Apr 2014, 11:15:47

+1 for the proposed solution.

Chriztian Steinmeier 23 Apr 2014, 14:16:04

PascalCase for doctypes and camelCase for properties always made perfect sense to me - especially in the XML cache (and in XSLT). Never was in doubt if a selection was targeting documents or properties. Thus, I'll add a +1 to the proposed solution.

Dan Booth 23 Apr 2014, 19:09:44

Stephan's solution works for me. Good input by everyone.

Stephan 23 Apr 2014, 22:20:33

Pushed ee210ae to 7.1.2 and f46811f to 6.2.0 that implement the following logic:

  • when a document type is created, the proposed alias is PascalCased
  • once it is created, it is possible to change the alias case to whatever you want
  • when a property type is created, the proposed alias is camelCased
  • but it is possible to change the alias case to whatever you want Seems to work OK, will do more tests before closing the issue.

Stephan 30 Apr 2014, 10:42:09

Seems OK, closing.

Priority: Normal

Type: Bug

State: Fixed

Assignee: Stephan

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 6.1.5, 7.1.1

Due in version: 6.2.0, 7.1.2


Story Points: