Eggmatters.com

Welcome to eggmatters.com! This is my "internet journal" or "web log." Don't get me wrong, I like the term blog. It kind of sounds like 'blargh" which kind of sounds like someone vomiting. Which, if you think about it, that's basically what most blogs are. A massive regurgitation on the internet. This blog is no different. I started this because I didn't take the hint from twitter or facebook that said "Nobody wants to read your long-winded blog entries." That shouldn't mean that I don't get to write them. There's gotta be some poor sap out there who would read something of mine and say to themselves, "Why yes, I did receive a modicum of entertainment from this"

At any rate, read on and enjoy and for god's sake interact! Leave me comments, send me a message with ideas, or suggesstions or constructive criticism veiled with sappy compliments. Because I don't take negative feedback very well. I will be adding features, expanding functionality and slaying haters, so stay tuned, check in and have a good time. Thanks!

Matthew Eggers (eggmatters)

Recently posted in: Poor Mans Framework

View this Post »

Chapter One Getting Started, Application Structure

Previous  Index

The Very Beginning

Starting out is the toughest. How many times have we just sat there looking at an empty project, maybe knowing how to begin - but not knowing how to begin properly?

Requirements gathering in the traditional sense doesn't apply to us as this is more of an exercise than anything else. The end user is most likely going to just be myself. But, I found that a great question to direct me during this process was this:

Don't ask what the application should do. Ask what value can it provide?

We will be doing what works for us. It will be a hybrid approach with the emphasis on the following factors:

  • Framework application space and user application space are clearly segregated and organized intuitively.
  • The application will be placed in a structured, secure location with only browseable content visible to the web server.
  • Configuration files shall be limited to the bare minimum of data and placed in a secure location out of the Docroot.
  • Changes and reorganizations of the filestructure can be done with minimal impact.
  • Persistence (databases, files) will be abstracted from the application and we will strive to keep these methods as the only configurable elements of the PMF.

Framework Code / User Code

If it's not patently obvious, Framework code is what we'll be developing here. This is the PMF as a product. The scripts we'll be writing here will mostly live in the "core" folder (see application filestructure below.) With a few files here and there as needed.

When I say "User" in the context of application development, we will be referring to a user of the framework i.e. a developer. Not a user of the finished product. User space is where a user will put application specific files. "app" is a common folder name for this space so we've done the same. Note that app will primarily consist of the directories "models", "controllers" and "views".

PMF and the Filesystem

Regardless of which webserver you're running (Apache, Nginx, Wamp, etc.) it is super important we keep the code out of the DOCROOT of the webserver. We will be redirecting requests (See chapter Three) but it doesn't hurt to be a bit paranoid making sure our webserver doesn't inadvertently attempt to serve scripts not meant to be accessed by request.

By default, Apache serves DOCROOT from /var/www/html. The html folder of the application will replace this folder and the other folders will live in the /var/www directory. That way, a call to configrations/ModelMapper.php won't inadvertently deliver all of our database users and passwords.

PHP Classes and Namespaces

Pretty much everything we will be writing will be PHP classes. One of the drawbacks of PHP is that it is not a fully-fledged OOP langauge. It supports OOP, but it is not Object Oriented. PHP has enough OO support however, that we can utilize most of the features we would expect from a fully-fledged object oriented platform.

We will be namespacing all of our classes respective to the directories they reside in. The benefit of this is that we will have clean segregation of concerns. An added benefit is we gain a huge efficiency with our autoloader (see Chapter two.) A drawback however will be keeping track of everything. In java, namespaces are a natural consequence of an application filesystem. If I had a library of classes stored under some folder "utils" I could just issue the statement "using utils/*" and have access to those classes. Unfortunately, PHP does not support wildcards with these statements.

PHP does offer a robust Reflection library. We will take advantage of this to determine which resources we need dynamically.

Convention over Configuration

This design pattern lays at the core of most application frameworks these days. It basically states that application structure as well as naming patterns dictate control flow. With MVC, we will expect controller classes to reside in the app/controllers folder, be a pluralized name of the model and end with the word "Controller".

RESTful requests will also be convention-driven. Since we know how any RESTful request is structured, we can analyze that request to dictate what is eventually served.

Persistence of Data

As I began this project, the one thing I wanted to do to set this framework apart from others is abstracting the data sources from the data models. In both my PHP and Rails experience, I was tasked more and more with integrating data deriving from both API calls as well as databases. I wound up cobbling together data models to mitigate both of these sources.

The application database will be accessed via an internal ORM. The database will, for this reason, need to strictly follow an established convention for table generation. This convention is adapted from Rails and we will be following these guidelines:

Another outlier, persistence-wise will be the session. We will want our application to be session aware and will use some conventional, tried-and-true practices to maintain session state.

  • All tables must be indexed with a primary key named "id"
  • All tables will be pluralized names. (i.e. users, posts, inventories)
  • Any foreign key relationships must be named <foreign-table-name>_id. A table posts, with a foreign key on users will have a column "users_id"
  • Any foreign key relationships will have defined contraints on the table they reside (this is important!)
  • Many-to-Many relationships must be related via a join table.

When we get to the ORM, you will see why - but maybe not in a way your were expecting. We will also write generation scripts which will automate much of this for us.

In Rails, for example, Database Models derive from ActiveRecord. API-based models derive from ActiveResource. There are subtle and not-so-subtle differences between these classes but they're both tasked with producing the same result. We're going to be separating models from datasources. Databases, API's, Files, MQ's etc will all be derived from a core class that models will request their data from.

Overall File Structure

The following is how I've structured this application so far. You are completely welcome to alter, rename or do whatever you want with it.

Additionally, There may be some hidden rabbit hole which may force my hand to reorganize. I'm doubting this but consider this notice that this structure is subject to change:

app                     -- User space
  |- controllers 
  |- models
  |- views
configurations          -- User provided configurations. 
  |- ModelMapper.php    -- a container for database and api credentials
  |- Application.php    -- this will be a container to provide application overrides.
core                    -- All of the framework code goes here
html                    -- Non-framework code (e.g. landing pages, 3rd party additions - like a shopping cart etc.) 

REST and the PMF

I will iterate this in nearly every chapter of this book / guide / whatever. RESTful requests will drive nearly everything. We will be focusing a lot on dynamically loading resources from requests. This will drive routing, dataloading and rendering - which is everything.

Doing things dynamically will get us far but, there is a payoff to this. We will be taking an efficiency hit in parsing this data. We will also unavoidably be doing certain things more than once. This is the tough part of application design. We are not so much tasked with figuring out how to accomplish this but doing it in a way that is as efficient and low-level as possible.

Conclusion

Remember, this is the "Poor" man's framework. It began as a pseudo-attempt to incorporate a more RPC-based application comprising of ajax calls for JSON as a more API driven application.

This application will be more robust than that. It will be RESTful, and have clean URL's and -- more importantly -- well defined contracts for negotiating requests. This is also an MVP and will not come out of the box with a lot of bells and whistles and robustness other frameworks may offer. We want to make sure that we do the basics well. Once we've established that, we can bolt on more features.

The PMF will attempt to achieve these goals:

  • Provide a generalized base to quickly develop a web application across a variety of specializations
  • Have as low of a footprint as possible.
  • Achieve Benchmarks beating other frameworks serving the same data.
  • Addition of other features should be done easily by the open source community without any application re-design or refactoring.

Pretty ambitious but, let's see where that gets us. I've already learned a great deal and see great potential for this. If not, I did in fact learn a great deal.

Previous  Index

Comment on this Post »