In javascript, I can define an object like this:

var object = { look: "ma", no: "quotes" };

Note the lack of quotes on the key names in the object.

Since JSON is a data exchange specification, it requires quoted keys.

So, if you want to put JSON into a data element, you need to do this.

<span data-stuff='{"i":"need","the":"quotes"}'></span>

Here is the relevant quote from the JSON documentation:

“When the data attribute is an object (starts with ‘{‘) or array (starts with ‘[‘) then jQuery.parseJSON is used to parse the string; it must follow valid JSON syntax including quoted property names.”

http://api.jquery.com/data/

These are still works in progress, but there is a Sinatra app called simply hooplanow_api_example for you Rubyists out there, and a wordpress plugin for those of you who have a wordpress blog, or want to take a peek at some PHP code that uses the API.

Neither is complete, but I would welcome pull requests from anyone who wants to help out.

svn cp {{trunk}} {{branches/blah}}

Sure, it creates a branch on the svn server that may or may not go anywhere, but it’s simple to remove it, so there’s no harm. It also feels a lot safer. Even my experimental code lives on both my system and on the repository server. My commits are getting smaller and more focused as well. Previously, I would often wait until a whole feature was complete before committing. Now, I commit each individual step.

When I’m done, it’s simple to merge back in.

svn merge -r{{start_rev}}:{{end_rev}} {{branches/blah}}

But what about conflicts, right? Git handles merging much better, but again, it’s an unfounded fear. Yes, if changes are made to trunk while you are working on the branch, you might get conflicts, but in my experience, conflicts are rare and the benefits of branching outweigh the risk.

It always confused me why it seemed like sometimes using the field name from the database failed to work in model methods that I wrote. When the method was simple, things would work fine, but then something would happen and it suddenly stopped working. I never quite put together what was going on until now. I would start out with something like this:

# Very simple, overused, contrived example
def full_name
  "#{prefix} #{first_name} #{last_name}"
end

It works beautifully and looks clean. But then, I’d need to add some defaults, like so.

def full_name
  prefix = "Mr." if prefix.blank?
  first_name = "First" if first_name.blank?
  last_name = "Last" if last_name.blank?
  "#{prefix} #{first_name} #{last_name}"
end

At first glance, it looks right, but it’s not. It causes full_name to produce “Mr. First Last”, every time you run it. WTF? Here’s where I would usually overreach and get it horribly wrong. I know that the fields are available as “self.field”, so I make one more change.

def full_name
  self.prefix = "Mr." if self.prefix.blank?
  self.first_name = "First" if self.first_name.blank?
  self.last_name = "Last" if self.last_name.blank?
  "#{self.prefix} #{self.first_name} #{self.last_name}"
end

So, one WTF leads right to another. This code is horrible. It’s ugly and it feels like there should be a better answer. In this example, it’s not so bad, but what usually ends up happening is this type of code gets written in a method that is already fairly ugly, and because of a simple misunderstanding, it goes directly from bad to worse.

Finally having some time, and just being fed up enough, I did some searching and found this. It ends up being fairly easy to understand once you think about it. In ActiveRecord models, the fields are methods. The way Ruby works, writing “field = ” creates a local variable instead of calling the “field=” method on self. It is the very act of assigning the field with a default that causes the issue. So, you can scale it back a little and rewrite the code like this. You only need “self.field” when assigning a new value.

def full_name
  self.prefix = "Mr." if prefix.blank?
  self.first_name = "First" if first_name.blank?
  self.last_name = "Last" if last_name.blank?
  "#{prefix} #{first_name} #{last_name}"
end

Much better.

First, let me say what I like. I love the M in MTV. Using the core models makes working with posts, users, attachments, etc, so much nicer than using the wordpress functions themselves. Because the project was so young when I first tried using it, it could be a bit frustrating to learn that something wasn’t implemented (like avatar images), but over time, that has improved.

I also like being able to create my own models, and MTV keeps storage a detail, so if I don’t want to mix my models into the wp_posts table (like built-in post types have you do), then I can do that.

I understand why it was chosen, and I like that it forces you to use better practices, but I really wish MTV would have stuck with PHP for html templates instead of going with Twig. It makes it nearly impossible to take existing themes and port them to MTV. It’s probably because I come from the Rails community where erb templates are just ruby. I’m sure having a full-featured language at your disposal in the view is exactly what the developers of MTV were trying to avoid, because it leads to misuse, but when you need it and it isn’t there, it’s can be really frustrating.

So, the verdict? Overall I like it. In my opinion, it still needs to mature before it’s ready for a larger audience to adopt it. I also have my own doubts that the wordpress community as a whole would ever adopt MTV or something like it. It would be for its own benefit, but the community seems to embrace its chaos rather than shun it. But that’s probably another blog post all together. It’s also one I probably will never write, as it would just be food for the trolls.