This project has moved. For the latest updates, please go here.

[POTENTIAL BREAKING CHANGE] Chalk Naming Conventions ($postID and $categoryID)

Coordinator
May 2, 2010 at 4:11 AM

Noticed that these were wrong in the documentation ($postID was $postid and $categoryID was $categoryId) and fixed it on http://graffiticms.codeplex.com/wikipage?title=Standard%20Chalk%20Items. However, with all of the objects, including the objects used by chalk, the ID portion of any property is cased "Id". I would like to change these chalk variables in the code to match, but obviously this would be a breaking change, so I wanted to get input first - if there's an overwhelming desire to keep them cased the way they are now or any great reason not to change them, then I won't make the change.

Coordinator
May 2, 2010 at 8:18 AM
Edited May 2, 2010 at 8:27 AM

I might be confused so I'll assume you are thinking ID is better than Id?? Yes the documentation is wrong and I'll fix that right now since you mention it. I think the way it should be is properly camel-backed, meaning $categoryId is correct but $categoryID is incorrect. The capital is only used as a way to indicate the next word and really has nothing to do with the fact that ID is normally capitalized in proper english.

ID related chalk objects are the most used so you would be breaking every template in existence and causing a great deal of work for anyone upgrading. (I'm assuming thats how you're wanting to change it?) So my vote is leave it alone. If a change were to be made at all it would be in 2.0 but even then I vote for CamelCase cuz thats how I roll.

To support my point to treat abreviations as lower case words, please read this short section on Wikipedia found here http://en.wikipedia.org/wiki/CamelCase#Programming_and_coding

Programming identifiers often need to contain acronyms and initialisms which are already in upper case, such as "old HTML file". By analogy with the title case rules, the natural camel case rendering would have the abbreviation all in upper case, namely "oldHTMLFile". However, this approach is problematic when two acronyms occur together (e.g., "parse DBM XML" would become "parseDBMXML") or when the standard mandates lower camel case but the name begins with an abbreviation (e.g. "SQL server" would become "sQLServer"). For this reason, some programmers prefer to treat abbreviations as if they were lower case words, and write "oldHtmlFile", "parseDbmXml", or "sqlServer".

I did find one odd exception in the documentation, EmailRequiresSSL, which I can justify since SSL is the last portion and as long as the documentation is correct, people shouldnt have much of a problem anyway.

Coordinator
May 2, 2010 at 5:55 PM
You are VERY confused with what I said. First, do not change the documentation. I already changed it to match the code (as I stated). Second, I said that these two fields already use ID and I want to change them to Id, to match everything else.

And I hardly believe that those two chalk variables are the most used; that honor would go to $post and $category.

On May 2, 2010, at 3:18 AM, "jkillebrew" <notifications@codeplex.com> wrote:

From: jkillebrew

I might be confused so I'll assume you are thinking ID is better than Id?? Yes the documentation is wrong and I'll fix that right now since you mention it. I think the way it should be is properly camel-backed, meaning $categoryId is correct but $categoryID is incorrect. The capital is only used as a way to indicate the next word and really has nothing to do with the fact that ID is normally capitalized in proper english.

ID related objects are the most used so you would be breaking every template in existance and causing a great deal of work for anyone upgrading. (I'm assuming thats how you're wanting to change it?) So my vote is leave it alone. If a change were to be made at all it would be in 2.0 but even then I vote for CamelCase cuz thats how I roll.

To support my point to treat abreviations as lower case words, please read this short section on Wikipedia found here http://en.wikipedia.org/wiki/CamelCase#Programming_and_coding

Programming identifiers often need to contain acronyms and initialisms which are already in upper case, such as "old HTML file". By analogy with the title case rules, the natural camel case rendering would have the abbreviation all in upper case, namely "oldHTMLFile". However, this approach is problematic when two acronyms occur together (e.g., "parse DBM XML" would become "parseDBMXML") or when the standard mandates lower camel case but the name begins with an abbreviation (e.g. "SQL server" would become "sQLServer"). For this reason, some programmers prefer to treat abbreviations as if they were lower case words, and write "oldHtmlFile", "parseDbmXml", or "sqlServer".

Coordinator
May 3, 2010 at 1:38 AM
Edited May 3, 2010 at 4:57 AM

I see, I wasnt sure what you were trying to "match" and what was being changed, the way the other object names are formatted or the way you changed it in the documentation. I say change it, its wrong the way it is currently. The variables I thought you were going to change are used considerably but those two are farily minor in my experience so I wouldnt mind it. If its not too messy, maybe support both and the old one can be depreciated/removed over time.

Coordinator
May 3, 2010 at 2:22 PM

I'd say in the interest of compatability we should keep the variable names as is for the 1.x. 

Coordinator
May 3, 2010 at 2:24 PM

I agree. Why is this SO important to make this breaking change in a 1.x release? Sure, in the 2.0 release go for it, but I wouldn't make a breaking change in 1.x unless it is absolutely critical. Just my opinion though.

Coordinator
May 3, 2010 at 2:34 PM
No one said it had to go into 1.3. I didn't even say that we had to do it at all. I don't see where anyone said it was "SO important", as you put it. I'm just looking for consistency in what is provided to the end users of Graffiti - the developers who have to customize it, a group that most people here are part of.

On May 3, 2010, at 9:25 AM, "madkidd" <notifications@codeplex.com> wrote:

From: madkidd

I agree. Why is this SO important to make this breaking change in a 1.x release? Sure, in the 2.0 release go for it, but I wouldn't make a breaking change in 1.x unless it is absolutely critical. Just my opinion though.

Coordinator
May 3, 2010 at 2:39 PM

I agree it should be changed and would vote for it to be in 2.0. I apologize as I made the assumption on your first post you were looking to do that right away.

Coordinator
May 5, 2010 at 3:10 AM

I think jkillebrew had a good idea to have both values available, at least in 1.3. And then just go with the correct case (Id) in 2.0. This way, people using 1.3 can still use the old value, but be ready for the migration when 2.0 comes.