We have moved to GitHub Issues
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!
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.
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.
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?
Vote: when I create a document type with a given name, should the first letter of the proposed alias be:
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.
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 :)
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)
@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. ;)
+1 on what Jesper says
+1 on what grumpy old man said ;-)
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.
@James - GetPropertyValue
This is just about the casing, where enforcing anything triggers riots in the name of backward compatibility...
@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.
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:
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.
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).
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.
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
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.
Soooo... '''CURRENT PROPOSED SOLUTION''':
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.
@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.
+1 for the proposed solution.
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.
Stephan's solution works for me. Good input by everyone.
Pushed ee210ae to 7.1.2 and f46811f to 6.2.0 that implement the following logic:
Seems OK, closing.
Backwards Compatible: True
Affected versions: 6.1.5, 7.1.1
Due in version: 6.2.0, 7.1.2