System Architecture

Benefits of Using the Hardhat Framework

Addictively Simple

I won't lie to you. Hardhat is not designed to replace all the other frameworks. It is designed
to be simple to use to develop websites and web applications.

If you are like me, you have had an experience
like this. You need to put up a website quickly for some purpose. You want to have some structure to it
because it may expand in the future, but you don't really want to go through the hassle of configuring
some framework for it. You long for a simple framework that will help you get it done rather than
get in your way. If this sounds familiar, Hardhat may be for you.

Say Goodbye to Back Button and Refresh Button Issues

Hardhat automatically replaces all post transactions with redirects to a get transaction
so it is not possible to accidently resubmit a form. Plus by separating the Post transaction from
the ensueing Get transaction, it makes a nice clean separation of concerns. This is an area that
I feel most frameworks overlook.

Posting data is fundamentally different than displaying a screen. With
Hardhat, the Post transaction is processed, data is updated (if it passes validation), and a Get transaction
is issued to display a screen. If the validation failed, it is likely that the input form will be redisplayed
with a message. If the update was successful, a confirmation page may be displayed. The point is, that it
is a new transaction, and if the user then refreshes the screen, it will reissue the Get transaction, not the
previous Post. This means they won't get the annoying "do you want to repost data" message.

I should point out that in the above scenerio, it is likely that it would never get that far because
Hardhat includes logic to help format jQuery commands for the jQuery validation routine. See the next
item.

Client and Server Validation from One Source

You can specify validation rules that will drive validation on the server and the client as well.
Let's face it. You have to have server side validation because you can't trust the client to
do it. But, client side validation is so much more friendly to the user. With Hardhat you can
specify the rules once and they will be used for both. Client side validation is done via the JQuery
validation plugin.

Schema Driven Design

Add a field to the database and it is available in the view. What could be simpler. Of course, if
you want to update it, there is still the process of filtering and validating the input before it is
inserted into the database. Hardhat will help you with that too.

Hardhat uses Smarty Templates

Smarty helps make sure your HTML looks like HTML and not a bunch of PHP code. It also helps you
to resist the temptation to put business logic in the view. Smarty is really a nice templating
engine, and for most things you only need to know a few key things, which are documented in this guide.

Ok I understand not everyone is a fan, but there are some good reasons to use it. If you really
don't like it, it is easy enough to just not use it and use pure php as a replacement. You can read
about why I like Smarty here.

If performance is your issue, remember that Smarty Templates are compiled the first time they are accessed, and
after that you are executing pure optimized php code.

Classes are AutoLoaded

Hardhat uses a classloader which contains an autoload procedure so that classes can be automatically
loaded when they are referenced. This eliminates the need for a whole bunch of require_once statements
all over the code.

Complete Control of URLs

Hardhat uses an xml file (commands.xml) to map all urls to action classes. This gives you complete control
of urls for search engine optimization, or even to redirect urls of a rewritten system. This also documents
all access into the system in one place. If it is not in the commands.xml file it can't be executed.

Some Frameworks, Code Ignitor and Zend to name a couple, use a controller model where
part of the url maps to the controller module, and part maps to the function within the module.
Here is the problem I have with that approach.

First it means that some code will be loaded that is not being used. It is doubtful that you
would be adding a record, deleting a record and updating a record all at the same time. So why would
you want to load all that code at once? Hardhat only loads what is needed for that particular
transaction.

More importantly when you are looking at the code, you can easily get lost and get the update record logic mixed
up with the add a record logic. If each module only did one thing, you would know for sure that everything
in there was related to that one thing.