Haiden Taylor

I would love to remake this template, using jQuery. →

Status Cats →

Very amusing

Obsidian|server:  hacks heckman's wifi-enabled toaster
MTecknology:  Obsidian|server: installing nginx on it to host porn without his knowledge?
Obsidian|server:  no
Obsidian|server:  i'm installing windows on it
Obsidian|server:  and i'm leaving it up to him to find all the drivers too

Zend Framework directory structures, Doctrine2 and where code should be placed

Zend Framework has a very well defined directory structure which gives the user a fairly good idea of which classes should go in what directory (Eg. Controllers in Application/Controllers).

As an individual coming from php development to Zend Framework was previously I had a very good idea of where I should place code and in what files, as I made the structure and perfected it over many projects. 

With Zend Framework I had to grasp the MVC concepts and also find the most appropriate places for my code. The difficulties primarily centred around my ability to make a functioning Zend Framework application while feeling that I had my code in the wrong place. Eg, controllers with many lines of code.

After reading many books on Zend Framework to try and establish appropriate placement and techniques I eventually formed my own opinion, which I would like to share here. I am hoping to fine tune this as I continue the development of my application, so check for updates.

Using bobbymcr’s disgustingly awesome ASCII directory structure. 

Directory Structure:

   |-application

   |—-configs

   |—-controllers

   |——-helpers

   |—-forms

   |—-layouts

   |——-scripts

   |—-models

   |—-views

   |——-helpers

   |——-scripts

   |———-error

   |———-index

   |-docs

   |-library

   |—-Asciant

   |——-Entity

   |———-Proxy

   |——-Form

   |———-Decorator

   |——-Repositories

   |—-Bisna

   |——-Application

   |———-Container

   |———-Exception

   |———-Resource

   |—-Doctrine

   |——-Common

   |———-Annotations

   |———-Cache

   |———-Collections

   |———-Util

   |——-DBAL

   |———-Driver

   |————-IBMDB2

   |————-OCI8

   |————-PDOIbm

   |————-PDOMySql

   |————-PDOOracle

   |————-PDOPgSql

   |————-PDOSqlite

   |————-PDOSqlsrv

   |———-Event

   |————-Listeners

   |———-Logging

   |———-Platforms

   |———-Schema

   |————-Visitor

   |———-Tools

   |————-Console

   |—————-Command

   |—————-Helper

   |———-Types

   |——-ORM

   |———-Event

   |———-Id

   |———-Internal

   |————-Hydration

   |———-Mapping

   |————-Driver

   |———-Persisters

   |———-Proxy

   |———-Query

   |————-AST

   |—————-Functions

   |————-Exec

   |————-Expr

   |———-Tools

   |————-Console

   |—————-Command

   |——————-ClearCache

   |——————-SchemaTool

   |—————-Helper

   |————-Event

   |————-Export

   |—————-Driver

   |—-Symfony

   |——-Component

   |———-Console

   |————-Command

   |————-Helper

   |————-Input

   |————-Output

   |————-Tester

   |-logs

   |-public

   |-scripts

   |-sources

   |-tests

   |—-application

   |——-controllers

   |—-library

A couple of things to note, I am using ZendCats’s implementation of Doctrine2 with Zend Framework, which accounts for the Symfony, Doctrine and Bisna applications in the Library. 

Now that you have an idea of the broader directory structure I hope to clarify some of the what goes where.

   |—-controllers

Is fairly self explanatory, of primary note here is that we are wanting to use the Fat Model Skinny Controller methodology noted in several books, probably most notable (at least in the books I have read):

• Zend Framework 1.8 Web Application Development; and
• Zend Framework Surviving the Deep End.

A quick note of Zend Framework 1.8 Web Application Development, while it is a few years old now, and a couple of iterations out of date, a large amount of the content is dedicated to understanding the Zend Framework and the best methods for code placement and their associated principles.

Back to the FMSC methodology, the main premiss is that we should push as much functionality as possible to the Model and use the Controllers to simply call the Model methods, and assign data to the view.

To the seasoned Zend Framework programmer this will seem like I am telling you how to suck eggs, but honestly, the message isn’t getting through from veteran to beginner.

   |—-controllers

   |——-helpers

The helpers directory is where I store my Action Helpers, action helpers are things which are reasonably common across all your controllers and then encapsulated within an action helper to avoid repetition.

   |—-forms

Forms are also fairly straight forward, a place to store your extensions to the Zend_Form class to present and validate forms.

   |—-layouts

   |——-scripts

For those who wish to use the layouts functionality to have a single master template file with each view script then only rendering content with minimal HTML, another way to avoid repetition.

   |—-models

Personally models were one of the hardest concepts to use correctly. Particularly when using Zend_DB. My lack of understanding primarily focussed around the ease of implementation of a Zend_DB_Table model which accepted only two variables to get up and running. Once I had the model working I would be very tempted to then place all my code into the controller, rather than making methods within the Model to do all the work. 

Whether through ignorance of the concept, or I simply fell into a trap for new players I failed to effectively use models.

After implementing Doctrine2 I was still slightly off track, although I knew something was wrong when I could make an entire action without calling a single model. The reason for this was I was using a Doctrine Entity, Entity Manager and a Repository if required to extract information from the database.

This overall reduced my lines of code in the controllers. After some further reading, particularly Zend Framework 1.8 Web Application Development, I realised the error of my ways.

Now I have created numerous models to handle my interaction with a database, each model being limited to a specific Doctrine2 Entity (or table) and I have, right or wrong, made the Model’s Resource a Doctrine2 Repository. 

While this has likely increase the number of files I have to maintain, it has loosely coupled them enough that a change to say the table structure would likely only impact one or two files.

I am not sure if I have done this section justice, it is the entire reason I wrote this article and in my opinion the source of much heartache when using Zend Framework. Even though you may be using a private codebase, there is still the urge to be following best practices.

   |—-views

   |——-helpers

Fairly self explanatory to, as mentioned above with Action Helpers, View Helpers encapsulate common code that appears across multiple views.

   |——-scripts

   |———-error

   |———-index

Your view files are stored here using the .phtml extension, right or wrong, as a general rule don’t limit yourself to just <?php echo $this->variable; ?> some basic coding in here is fine, as long as you aren’t writing a novel.

   |-library

Within the Library directory is where code that is not specific to an application is meant to be stored, although this is not always the case.

   |—-Asciant

   |——-Entity

The answer to the ultimate question is not 42 →

Realtime user analytics →

Git Instructions I really need to remember

Global setup:

• Download and install Git
• git config —global user.name “Haiden Taylor”
• git config —global user.email haiden@asciant.com

Next steps:

• mkdir test
• cd test
• git init
• touch README
• git add README
• git commit -m ‘first commit’
• git remote add origin git@github.com:Asciant/whatever.git
• git push origin master

Existing Git Repo?

• cd existing_git_repo
• git remote add origin git@github.com:Asciant/whatever.git
• git push origin master

Error, what error!

An error has occurred, four words that every software developer knows all to well. Its a fact of programming life, at least every decent programmers life. Unlike your television, your car, or often in my case, ride on lawn mowers, just stop working without anything more than a cough or splutter is absolutely unacceptable to web users.

Think of it like this, when an error occurs on a web site, the end user isn’t interested in the details, they just see the markers. Tell tale signs of problems, the red font colour, the popup boxes, explanation mark images and more importantly, the lack of the requested operations output. Using the cough and splutter example, when a my mower run out of fuel the other day, it coughed, spluttered and very soon after, the engine stopped.

Tell tale signs that something has gone wrong, but whats the end result, I am not mowing anymore. So I open up the hood and take a look, I can see their is no fuel, I fill it back up, start the mower again and happy days.

What happens when a web site doesn’t do what its meant to, if programmed correctly the application identifies the error, degrades as gracefully as possible and shows the user a rough explanation of the error. What is the end result, the user isn’t able to do what they requested.

So what happens next is a problem thats not unique to the web, it relates to a lack of understanding. The user just clicks refresh, again and again, since generally the data operation is processed over and over again, generally the same error is displayed over and over again.

Its similar to when a new driver hops in a car and something goes wrong, in these cases its not un-common for the driver to simply turn the engine over and over again until eventually flattening the battery.

So what is the best way to handle it?? The short answer is, there is no right or wrong answer, just handle the problem as well as you see fit.

Having recently moved to the Zend Framework, I have been working on getting my head around its programming style and quirks. Although one thing still irks me, what to do with an error?

In the interests of not having repetition in my code, I don’t want to be pushing a $error variable into every template file, just in case something happens. But I also don’t want to be pushing exceptions out for every little error, especially since production Zend Framework only displays “Application Error” to the user on an exception.

So I am guessing that its about finding a happy medium, of not to many exceptions, versus $error variables. Interestingly Zend Framework aficionados that I speak to don’t seem to have an answer, its basically a “don’t through your users exceptions for everything”, but also a “use them were necessary”, along with my favorite “handle them in the controller”.

If anyone has any suggestions, please let me know.

Until then I will be working on possibly using a view helper, or possibly using a class which extends Zend_View.

Controller vs Model, Potato vs Potarto

As I get deeper and deeper into Zend Framework (ZF) I have found some of my old habits coming crawling back. Like for example, I have never liked camelCase, as a matter of fact I dipised it, I loathed having to use it to be compatable with the Zend Coding Standards.

I know, really, its my application, and I can code it how I like (I’d like to thank Lesley Gore). But that is not what learning a new framework, or a new language, is about. You don’t join a team and then decide its them with the problem not you, especially if there paying the bills!

Now back to my old habits!

Not using Camel Case

When I am writing a method, I first think to my self, this is what I need it to do. I then pour through articles, tutorials, the reference manual and most importantly the API’s. Once I have functionality I am looking for, or at least a rough idea of what ZF objects I need to use to get the job done. From there, I just write code.

I then get to the illusion of the end of the method, with a triumphent grin, I click refresh! behold +infinity tried to call a method of a non-object and unknown method…

Once I have figured out which getAdapters() and setAdapters() I need to put where, I look back over my code!

And every variable is named $db_select, $view_object, $permissions_array etc.

A defeated groan is all that I manage to utter. Knowing that my naming conventions are exactly what I want, only not what I should have!

I then head back through and fix all my variable names to $dbObject, $viewObject and $permissionsArray. Damn the man!

Controllers doing a hell of a lot of Modeling

My other problem, if a class is named SessionsController with an action of PasswordReminder fairly well says to me, set a hash in the DB, e-mail a link to the user to click to reset their password.

Aparently, it means:

1. SessionController->PasswordReminder()
2. Then passes over to the Password Reminder Model, which does its stuff, and lets the Password Reminder know when its done.
3. Password Reminder tells the view to do its crap!
4. Whammo, MVC or DIE IRL!

Funnily enough, even when writing the above process, it just makes sense. But its still annoying that I have code stored in three (Model, View, Controller) locations to do the same thing.

The problem is that secretly, I hate composition! Objects making Objects its just Sacrilege.

Well thats all for now, I have to move code from Controller to Model. Or I might get struck by lightning!

Authorisation vs Authentication

Just reading an interesting article on the Packet Publishing website regarding Zend Auth. The author, Keith Pope begins the article by defining the difference between Authorisation and Authentication.

Before we go any further, we need to first look at what exactly authentication and authorization is, as they are often misunderstood.

Authorization is the process of allowing someone or something to actually do something. For example, if I go into a data centre, then the security guards control my authorization to the data centre and would, for instance, not allow me access to the server room if I was just a visitor but would if I worked there as a system admin.

Authentication is the process of confirming someone or something’s identity. For example, when I go to into the data centre the security guards will ask me for my identity, which most probably would be a card with my name and photo on. They use this to authenticate my identity.

These concepts are very important so make sure you understand the difference. This is how I remember them:

Authorization: Can they do this?

Authentication: Are they who they say they are?

Really interesting definition, especially for people who, like me, couldn’t quite get there head around OpenID’s principles.

I have conceded defeat..

So in case you haven’t already guessed, I am moving exclusively to the Zend Framework. I have developed many a site in PHP, but nothing I was quite ever happy with, there was always something niggling in the background. Just looking through my old phpDEV code makes me cringe.

I had a very good look at cakePHP, but while good, there isn’t much of a take-up in Australia. So its not a viable option, having looked at positions for Zend Framework PHP developers I had decided to look at ZF. After doing some playing around, I have come to the conclusion that its the future of my development.

A site idea that I have been playing around with for a million years I have completed in a day. I will hopefully have the back-end completed in the next couple of days. Then its all front-end! That is what actually attracted me to the Zend Framework and now has me convinced that I would be simply wasting time developing without it. Unfortunately I don’t have the full time resources to dedicate to doing the development I would like, so I’m taking this step in towards ZF.

Its actually exciting, instead of ripping my hair out in the minimal time I have to devote to this interest of mine. I now have the opportunity to actually make some of the stuff I wanted to, rather than focus my time entirely on written my own variant of a framework so that I can then go on to make these sites.

So looking forward, I hope to get some of the sites out there that I have had on the back-burner, until I sorted what back-end I would use.

Inheritance, Overriding and Polymorphism

I was just reading through some of the cakephp code to try and figure out how my DBO fits into an MVC. It turns out that I am wayyyy off track, and the way cakephp does it completely makes sense, which is normally not how it works for me.

Basically Cakephp has written a datasource class which extends the base object, followed by a dbo_source class which extends the datasource class then a bunch of vendor specific dbo classes (dbo_mysql, dbo_mssql etc.).

Apparently, from what I can tell, these vendor specific classes extend the main dbo_source class, although where required the vendor class overwrites the dbo_source class with vendor specific functions / SQL. This means that if MySQL uses a specific syntax it will be overwrite the dbo_source class and BAM everything falls into place!

Seems pretty good in theory :P

I am perplexed!!

I have started working in secret, in a dark and dingy bunker, somewhere on an MVC framework. Not for production, but for my understanding of the pattern, it is indeed a challenging exercise.

I am currently stuck somewhere between controller and model. The problem I have is probably very simple for someone who knows there way around the architecture.

Say I wanted to create a new list item, using Anant Garg’s example. My URL would be:

• example.org/list/new

Which would create a new instance of the list controller, which extends the application controller. I would also be creating a new instance of the New Model?? I am really confused. It seems to make more sense that I would make an instance of the list controller and the new method. But then where does the model come into it.

I guess it seems logical that the instance of the list controller calls the new method, which composes a new instance of the list model which pulls whatever it needs from the database, sets any required template (view) variables, and then returns the data which the list controller then passes to the new list view.

I hope that this is the correct method, I guess it follows the principles of the MVC framework that I have read.

Only time will tell I guess!

Exception Handling

Its funny, for someone who is reasonably new to exception handling, I clearly overuse it. I need to find a balance!

“You should not use exceptions to control routine application flow, because that would adversely affect the performance of your application.”

- Kevin McArthur

"Checking the factories implement the appropriate interfaces"

— http://github.com/Asciant/savory/commit/1660f1d200197a373a006e8116ad50eeeb8fc700