No SES URLs in Model-Glue:Unity?

A few people have asked if there will be increased support for search-engine safe (SES) URLs in Model-Glue:Unity. In short, the answer is: no. There's just no need.

There are established and well-tested ways of creating SES URLs via Apache's mod_rewrite and rewrite plug-ins for IIS. There's no need to add the additional complexity of something like Rails' "routes" functionality.

Sorry if this disappoints anyone, it's just not something the framework needs to be involved with.

20 comments - Posted by Joe Rinehart at 10:09 AM - Categories: Model-Glue

(Parody) My New Web 2.0 App

I read a lot of things these days that describe "Web 2.0" applications no one has ever seen that'll probably never make it past a seven-year public beta.

A lot of these sounds like rants that George Carlin does in which he (very impressively) strings together a suprising number buzzwords that surround a given topic.

So, here's the description of a Web 2.0 app I'm deploying to beta in Carlin-format:

I've just written a new app. It's Web 2.0.

It's an agile waterfalled Scrum app written using Extreme Programming methodologies.

I've got test-driven development using a unit testing framework integrated with a build tool that autocompiles upon saving in my IDE.

I've got intellisense, my management methods follow common sense, and my SQL doesn't make others wince.

I've got ORM, which plays well with my database, which, of course, follows third norm.

It's got a full-stack framework, guaranteed to work, as long as I get latest from SVN, retest, and redeploy every day.

The data-layers hotswappable. Want platforms? It'll do MySQL, MSSQL, PostgreSQL, Informix, and even a flat file format your TI-85 could read. Oracle, as always, will cost you extra.

What about the .NET threat? You bet. It'll do ODBC, RDO, DAO, ADO, OLEDB, and now ADO.NET.

It's got CSS that even Eric Meyer would bless, not a tabled mess.

There's IoC, eliminating dependency, finding components on the fly, because I'm a decoupled kind of guy.

Objects? It's got a domain model to make you drool. There's a service locator, witty implementation of Decorator, and a data-layer cache that'll save you cycles now and later.

Through super decoupling configured by XML, there's no JAR FUBAR or DLL Hell.

I don't even code, I just add an XML node.

Speaking of XML hacks, how about that AJAX? I'm prototyped, script.aculo.us'd, unobstrusive, and them's the facts, Jack.

My code is patterned, not scattered, deep fried, and battered.

I've got object think (wink wink), but without the kitchen sink.

I've got a social network, chat rooms for the l33t to lurk, and it'll get Digg'd five thousand times per day.

It's a rich internet application, guaranteed to bring home the bacon.

It's using MVC, so it'll also work via HTML, SMS, WML, and a format known only to a hyperintelligent cat living in Tallahassee.

What does it do, you ask? It's a mobile platform for allowing user-contributed content synchronization across business domains integrating granular banded reporting of tags to account for the actual utilization metrics for every task.

12 comments - Posted by Joe Rinehart at 9:56 AM - Categories: Causing Trouble

What's with variables-dot-underscore in my CFC's?

I've had a few people ask me why I often have variables named things like "variables._foo" inside of my CFC's. Specifically, they're wondering about the underscore. In short, it's all about protecting data in the variables scope.

Expanded version of that one-sentence explanation:

If I've got something used by multiple methods in the variable, like a reference to a bean representing datasource information in a DAO, it gets two things: an underscore and a private getter method. Like this:

Why?

It means that if I accidently to this in some function, forgetting to var scope...

...I'll have only overwritten variables.datasource, not the variables._datasource that everything else uses.

In other words, it's just a quick way to prevent me from harming myself or others with a sloppy error that'd be hard to trace down.

5 comments - Posted by Joe Rinehart at 3:44 PM - Categories: Best Practices