Jesse Caulfield

I knew this was possible, but wasn’t sure exactly how.

:%s/[A-Z]/\l\0/g

or

:%s/[A-Z]/\L&/g

We’re trying to create a series of cross-referencing database tables in MySQL using foreign keys. However, despite following the documentation the linking did not seem to work.

I found that MySQL by default uses MyISAM for the DB engine, which does not support FOREIGN KEYs.

The solution is to force MySQL to use the INNODB engine.

For example: This will not work.

CREATE TABLE parent (id INT NOT NULL,
PRIMARY KEY (id)
) ENGINE=MyISAM;
CREATE TABLE child (id INT, parent_id INT,
INDEX par_ind (parent_id),
FOREIGN KEY (parent_id) REFERENCES parent(id)
ON DELETE CASCADE
) ENGINE=MyISAM;

This is how is should be written:

CREATE TABLE parent (id INT NOT NULL,
PRIMARY KEY (id)
) ENGINE=INNODB;
CREATE TABLE child (id INT, parent_id INT,
INDEX par_ind (parent_id),
FOREIGN KEY (parent_id) REFERENCES parent(id)
ON DELETE CASCADE
) ENGINE=INNODB;

A frustrating detail.

This week I sat down with Shep Kendall, an old friend and colleague, at a local Starbucks to discuss web applications. Shep accomplished in 20 minutes what 6 months of casual inquiry could not: explain clearly how things are done today, what is the model-view-controller architecture, how one would employ it, and why one would bother.

As background, fresh out of college I was the “resident HTML expert” and developed the first CGI codebase for Proxima (later Proxicom) that we used in our non-static web sites. I’m dating myself to say this was pre-Netscape IPO, but the point is that dynamic web services then relied exclusively on a client-server model. Dynamically generated HTML pages were created on the server and dynamically linked to other pages or CGI scripts.

Each browser page query was stateless and cookies hadn’t yet been invented. Stateful, multi-page transaction required values (like shopping carts) to be encoded and propagated within the URL. There was also no Javascript yet and the browser function was limited just to rendering HTML. Folks still used the <flash> tag and animated GIFs were still considered cool.

This basic client-server (CS) architecture I worked is still widely in use today in the guise of pre-processed HTML techniques like PHP, JSP, etc. where the HTML pages and CGI-BIN programming logic have been combined.

Client Server Model, or Sweet Nostalgia:
How we built web applications back in the day

Over the past decade however a whole new corpus of technology has been developed. While the end result is the same (rendered HTML) there are few other similarities to how dynamic web services are implemented today.

The most important development is in today’s browsers, which are infinitely more flexible platforms capable of “client-side” processing and logic through the use of Javascript, Flash, Active-X and other virtual-machine plug-ins. This has also enabled the server side to evolve.

The client / server evolution also enables a more optimised web application delivery achitecture. The addition of intelligence in the browser basically means that an HTML “page” is no longer a static, stateless object, but rather the canvas (or framework) within which information may be rendered according to user inputs (clicks, drags, etc.) The innovation called Web 2.0 is essentially an intelligent browser that can dynamically update portions of the rendered HTML on-the-fly.

The most scaleable architecture I’m aware of for such dynamic web services is Model-View-Controller, or MVC. MVC, like the client / server model illustrated above, also isolates business logic (programs) from the user interface (browser) while adding a two-day communications concept directly between the browser page and the server.

In layman’s terms, this means the browser fetches a page while the page fetches its own content.

MVC Model: Enables dynamic, user-driven content

In the MVC architecture configuration shown the web server is Apache. A separate application server called Tomcat is also installed. Tomcat may also run on it’s own without Apache. In the scenario illustrated above Tomcat registers its services (servlets) with the Apache web server and maps them to URLs. The net effect of the above configuration is that URL requests are directed either to HTML pages via Apache or to servlets via Apache + Tomcat transparently to the user.

The important addition to the earlier CS model is the concept of servlets, which are essentially funtion-specific web servers. In practice, servlets are paired up with Javascript/Flash/Active-X functions on the web page, respond to specific inquiries and send data formated for the requesting function. For example, a function to create a table display will be paired with a servlet that sends data in tabular format.

Servlet example: executing a database inquiry and formatting the data into a JSON-encoded object

It’s helpful to “follow the token” and the transaction flow for a page-load and subsequent page data request are illustrated below.

Page and page data transaction flow

A brief word about libaries and frameworks

There is a tremendous amount of configuration required to get all these pieces working together properly. Software frameworks have been developed essentially to automate the process of registering servlets and their capabilities, then exposing their data to client browser functions. Framework examples include Sprint, JBOSS, etc. More on frameworks at a later date.

Links >

• Model–view–controller
• PHP
• Shep Kendall
• JBOSS
• Spring Framework