In my recent post regarding the Model Service layer, there was one query about me mentioning that the View is configured by the Controller which goes against the grain of traditional MVC idea of “Views Should handle their own Models / data”.

There is nothing wrong with Views being able to handle their own models, I’m not suggesting that this shouldn’t be the case. You can also do it this way. That is the “traditional MVC” way of doing things and it works fine which is why I’m questioning why I’ve moved away from it. I’m just typing as I go so hopefully by the end of it, we’ll have something that makes a point.

I used to Really love this sh*t!

I used to trumpet the sh*t out of this because I had it figured out and it made me feel smart . I thought hey, I can adhere to the traditional MVC way of things and make the View select it’s own Model (or models) and gather information on it’s own – all I need is a View Helper. Further along came the question “What about the times when the Model needs to be used by the Controller?” well I got a plan for this too, then there’s the “What about when the Controller and View need access to the same model?” case. I needed to create a strategy to make sure that the Model isn’t instantiated twice in these cases.

This is how I did it: Components you need to code up to make it so that the View can choose it’s own Models

Step 1: I created a Model Service Factory which I stored in Zend_Registry – the Model Service Factory has a Registry of it’s own and checks to see if an instance of the Model being requested already exists – if it does, it returns that instead of creating a new instance.
Step 2: I created a View Helper called “GetModel” which accesses the Zend_Registry to access the Model Service Factory and returns the model
Step 3: I then created an Action Helper called “GetModel” which worked exactly like the View Helper.

But then, I found myself questioning if the view selecting it’s own models / data applies to PHP, or if all this complexity is worth anything useful aside from saying “I can do it”. Here are some of the things I’m thinking about:

• One of the cases that I’ve found cumbersome is when I need to access  request parameters in the View whether it be for creating a URL. This should be regarded as a data source as well. Does this mean that we have to code up View Helper to access this also? (This isn’t a smart ass rhetorical question either – I really want to know what do you do?)To handle cases where I need to display parameters in the view, I assign the view parameters in the controller something along the lines of:

$this->view->username = $this->_getParam(‘username’);

• Say you need to display session data in the view, how would you go about doing that? Personally, as with the request parameters, I assign the session data to the view in the controller:

$this->view->somesessiondata = $session->somedata;

• Now say we need to get some data from the model… no problem!  I can use the getModel view helper that makes me feel so smart. To do this though, we need to set up the view so that it has the ID parameter.

$data = $this->getModel(‘SomeModel’)->findById($this->id);
// or if we us a view helper for parameters (I said IF – not entirely sure about this yet)
$data = $this->getModel(‘SomeModel’)->findById($this->getParam(‘id’));

Now compare this with providing the data that the view needs via the Controller.

// in the controller
$this->view->data = $this->_service->findById($this->_getParam(‘id’));
$this->view->username = $this->_getParam(‘username’);
$session = new Zend_Session_NameSpace
$this->view->sessionData = $session->sessionData;

// in the view
<h2>User Details</h2>
<?php foreach ($data as $key=>$val) : ?>
<?=$key?>: <?=$val;?>
<?php endforeach; ?>

<p>You have requested the username: <?=$this->username; ?> which is not available. </p>

Also at one point I was thinking why we are fighting so hard to decouple the view from the controller anyway? They are coupled from the file system and have default conventions like indexAction is coupled with index.phtml view script in an index script directory (which matches controller name).

Having said that though, I don’t see a strong case for or against pushing or pulling models to or from the View. Maybe I’m just missing the point somewhere. In any case, I’d be grateful to know (and learn from) what your take is on this subject matter.

So to sum it up, these are the questions that are floating through my head at the moment.

• What are the _specific_ advantages of having the View pull data from the model directly?
• What are the _specific_ disadvantages of having the Controller push data from the model into view member variables?
• Is the example I specified above (creating view helpers, registry, action helpers) overkill just to achieve something that may or may not be a design problem?

After some more thought and lots of research on the subject, I’ve come to a solid point where I actually have something to try out which seems semantic aside from the naming of the class (Service Class) – but this is derived from what some people are talking about in ZF circles starting from Matthew Weier O’Phinney who was coining it as the “Gateway to the Domain” from early on, then later changing it to “Service Class”.

The Service Class

So this is what I chose to go with:  For each model class, I’ve got a Database Agnostic Service class - in fact, it uses the Entities Produced by Doctrine ORM to talk to the database, but isn’t entirely reliant upon Doctrine to Provide the Model Layer on it’s own. Using Doctrine as your Model Layer alone I suppose is better than extending Zend_Db which is highly discouraged by everyone, but you still have the database dependency.

I thought well, I’ve done a lot of feeling around the subject, maybe I’ll just ask around. So over to twitter I go. I sent Matthew Weier O’Phinney a tweet asking if it is right that Doctrine models are relatively empty whilst Model services are filled with business logic and he answered: “Absolutely. Plain old PHP is perfect for entities.” but I had no idea WTF that meant.

The Service Layer uses the Model which is the Entity. My further attempt to clarify the situation and continue discussion didn’t get a response – maybe because I had to condense words and use accronymns to fit the message in or he had just become too busy. So on my own I go again.

After mulling over it a few, I thought I’d just run with what I’ve got. It seems to be semantic, but it has a lot of responsibilities:

• The Model Service Class is a Resource.
• The Model Service uses the ACL layer to check if a Role Identified has the Privileges to make it’s request prior to usage.
• The Model Service creates Entities by using its Model Factory/Finder methods such as FindById it then returns either an array or an Entity based on what Hydration mode was specified (default is array).
• The Model Service creates Forms and uses it for Validation
• The Model Service provides the CRUD methods so that the Controller does not have to worry about instantiating and configuring models to Create Update or Delete data.
• The Model Service uses Zend_Cache and can use caching on non-changing data such as lookup lists status or types and large collections of data used in drop downs, lists or datagrids.
• Although there is no factory for it, the Model Service can create and use other Model Service classes.
• The Service Layer is not passed to the View either. The View is configured by the Controller and has data shoved into properties/member variables.
• The Service Object can be passed to the View if required, so that the View can use the Sevice object to interrogate models on it’s own. We trust that those writing the View Markup will only be using the service object _strictly for reading only_.

I’ve been working with this setup for a few weeks now. This method is very testable and makes for an extremely thin Controller Layer.

What do you guys think?

Have we over engineered this thing? Should it be called the Service Layer as more and more people are coining it as? What suggestions can you make to make this better?

Zend_Navigation makes the management of a web site’s navigation very easy as it allows you to programmatically create the navigation bar by specifying either the URI or Controller, Action and Module properties of a Zend Navigation Page.

To use Zend Navigation, all I had to do was the following:

• Add configuration entries for navigation in the application.ini file.
• Initialise and attach an instance of the Zend_Navigation container class to the navigation helper via the view in the bootstrap.
• Display the navigation bar with Zend_View_Helper_Navigation::menu() or the BreadCrumbs with Zend_View_Helper_Navigation::breadcrumbs() in your layout.phtml file.

Add configuration entries for navigation in the application.ini file

Now I could have configured the Zend_Navigation container by passing the configuration options in an array, but I thought specifying the navigation in the application.ini was easier because it would keep my init method leaner (more on this later). So the first thing I had to do was add configuration entries for navigation in the application.ini file.

Here’s a code sample:

; —
; Navigation
; —
navigation.home.label = home
navigation.home.controller = index
navigation.home.action = index
navigation.users.label = users
navigation.users.controller = system-user
navigation.users.action = index
navigation.help.label = help
navigation.help.controller = help
navigation.help.action = index

Initialise and attach an instance of the Zend_Navigation container class to the navigation helper via the view in the bootstrap

Initialise the navigation object in the bootstrap class – well there’s no explanations needed here. See the code sample.

Here’s a code sample:

protected function _initNavigation()
{
$this->bootstrap(‘layout’);
$layout = $this->getResource(‘layout’);
$view = $layout->getView();
$navigation = new Zend_Navigation($this->getOption(‘navigation’));
$view->navigation($navigation);
}

Display the navigation bar with Zend_View_Helper_Navigation::menu() or the BreadCrumbs with Zend_View_Helper_Navigation::breadcrumbs() in your layout.phtml file

The Navigation view helper has methods such as menu(), breadcrumbs() and some methods for generating a valid xml sitemap() of the navigation container. You already know this, but I’ve included a code sample of how to do this with the menu() method of the Navigation view helper for completeness.

Here’s a code sample:

<!– left –>

<div id=”left”>

<?php echo $this->navigation()->menu(); ?>

</div>

<!– /left –>

While TDD has many benefits, my favourite is that it helps to keep me and the other developers on my team focussed on the components we have chosen to work on. Not only that, but it helps us focus on the task at hand as it forces us to think about each unit of the component and write it so that it _can_ be tested – as much as I’d like to expand on TDD itself, for this post, I’m just going to explain how it could help you keep focussed.

How does it keep you focussed?

Let’s take creating a user login form as an example. One of the key requirements for the application we are developing is to have a password protected administration area which requires a predefined username and password to enter. The ACL is dynamic, so an administrator has to have the ability to list, add, edit and delete users. Once the user is added, they can use the login form to identify themselves to the system with the username and password assigned to them by the administrator.

Now just as I’m typing this, a flood of components that will need to be written is coming to me - you’ll need the following:

• You’ll need, of course, the Login Form itself.
• A User Model, then the corresponding validation which will be taken care of via the form, but still you need to make sure that this ties in with everything.
• User Type and User Status Models.
• You’ll need an ACL Component.
• I like to Access to all this model functionality is simplified via a class that’s been coined as the Model Service class.
• You’ll need to Create Controller Actions.
• Along with Corresponding View Scripts.

How are you going to keep your focus with so many parts? You start from one point (the controller), make a list and start writing the application and start with “code”, “see if it works”, “next thing” kinda fashion. But what happens when you need to add something, you get called away from your desk for whatever reason (clients, ad hoc meetings etc)?

You will lose your train of thought, spend at least 20 – 30 minutes to get back to where you were and ultimately lose your focus – things are a little harder to picture. With Test Driven Development or TDD for short, we develop applications by writing the test first – the test is named as close to the business requirement as possible (such as “TestCanFindUserByUsernameAndPassword”), we write code to pass the test, then we write the next test.

I find that this keeps me focussed because when I step away from my desk or move onto other things during the day, I can come back to my unit test, and continue working from that point forward. I can focus on the task at hand since my only goal is to pass the last test I created before writing the next test. Before I know it, I’ve run out of tests to write and I’ve made several assertions on results and expectations.

Peace of Mind with TDD

There’s also the peace of mind factor – which is my second favourite benefit. You have peace of mind because you can be a little more confident that your code is working when you use TDD. This is because you have tested your code unit by unit as you wrote the application in iterations. Rather than writing the application as a whole, then testing each publicly accessible component over and over again.

Now I know that there are days when you’re just “In the Zone” and you will know where all this stuff is, what to do, how this all ties in to the point where you do a functional test and you achieve absolute perfection! But there is a reason that this is regarded as a “marveled feat” because it’s almost impossible to do and you need everything to go your way (no distractions, stars have to be aligned etc). But know this, even though you have developed the app and have tested a single method of usage, what’s to say that when it’s used in other ways it will still work?

I know this from experience and the following will happen to you:

• You will miss things.
• You go over things several times and even then still, you will miss things.
• You do lengthy functional tests over and over again because you’re paranoid (you’ve missed things before).
• You get the “that was too easy” feeling and start checking again.
• Finally, there’s the part where you think you’ve got it all submitted it to the client and then they find that you’ve missed things.

Trust me, regardless of how good a developer you are, you are susceptible to missing things. I had a junior one time who seemed to be a bright kid. Knew a lot and had the some work ethic. The developer would make up stories about friends of theirs who code in this way and write “perfect code” – I’d shrug it off and simply refute that they haven’t tested enough.

Funny enough, the more we worked together, the more I noticed that this junior worked like the fabled “perfect code” developer, but when tested enough times, bugs upon bugs upon bugs would start cropping up – thankfully this relationship is in the past which is where it will stay. There will be no way I’d be recruiting this person again. This person does not inspire confidence and really gives me no peace of mind.

If the junior dev at least knew Unit Testing, then I’d sleep easier knowing that the code they wrote is backed up by Unit Tests. I know the units of the components developed works as intended and changes can be changes can be tested easily.

Anyway, I guess this fast 15 has again gone way over time. So I’ll wrap it up here. See you on tomorrow’s fast 15.

Want to know about TDD?

I understand that this is a very general post about TDD, so if you would like to know more check out the following links:

• Test Driven Development on Wikipedia.
• Unit Testing Screencast at Zend Casts.
• The PHPUnit Unit Testing Framework

The Developers urge all 1.5.x users to upgrade _now_

More details can be found on the official announcement: http://www.joomla.org/announcements/release-news/5212-joomla-157-security-release-now-available.html

Find your update package here: http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=3947

Several hours later, I’m bumping into inline styles, redundant div nesting and crappy css! FFS I just wanted to change a couple of defaults! VM team! Please update your default template to use semantic mark up!!!! I can’t put it anyother way… The default virtuemart theme is a piece of $***.

Anyway, perhaps I’ll go ahead and create a skeleton theme with nicely structured html documents and clean CSS… The problem is, as you may have guessed, I never have any free time nowadays. If you’ve found one, please feel free to link feed me

– OT –

Oh yeah and just an update on life as requested by some of my readers- it’s good, very busy… having a great time living it! Sorry I’ve not had the time to reply.

– /OT –

Versions affected: 1.5 – 1.5.5
Solution: Download the patch and Upgrade to 1.5.6 -> http://joomlacode.org/gf/project/joomla/frs/

More details about this vulnerability can be found on the following URL:
http://developer.joomla.org/security/news/241-20080801-core-password-remind-functionality.html

Let’s not forget what classes and its methods are supposed to be: Classes are blueprints for specialist components and their methods are singular actions which address one to a few (2 – 3 at most!) procedures at a time whether it be through the use of other classes or just through simple logic!

DO YOURSELF A FAVOUR! Write smaller specific class methods. I know it’s hard to get your head around. When I initially started doin’ it the right way, I thought that it was “fragmenting” the logic which seemed counter productive at the time, but with practice, you will find that encapsulating logic into small methods _AT THE RIGHT PLACES_ actually makes more sense than putting a whole chunk of logic in the one method.

Think about it – it’s the amateur spaghetti coder within you that’s trying to shove in all that logic into the one method – think back to when you first learnt how to program! Cramming all this logic into the one method is the same as the time you were doing with a single PHP page that grew to 2000 lines, a bloated function, an abused case statement or all that SQL you placed in the view layer and said that it was right because it’s convenient – It’s saying “I think we should do it this way because it’s easier… well for me it’s easier anyway…”

What will happen if you keep creating bloated methods is that as your code “grows” (into a monster), is that it will be harder and harder to maintain and test each unit of code because they’ve become so big!

“It’s not so hard, I know exactly where I put my code…” you say to me as you look over your shoulder tapping away at your giant method.

Let’s see you do that in 2 – 3 months time _after_ it’s released and we find some bugs or asking you to make a change. The number of changes then become an issue – instead of weeks or days you’re thinking months and semesters.

“You’re making too many changes! This is going to be hard to do. Well, not hard to do but time consuming.” You reason as you mess around with your search and replace and write a list for yourself on the whiteboard. How is it my fault that the crappy code you wrote is rigid and brittle?

Expect change and expect them occuring in random! Write code that is easy to follow and is straight forward. Documentation will not cover everything and it’s crazy to say that it does – I don’t want to spend time writing up sentences of instructions on how to use a method.

Writing smaller methods and semantically refactoring your bloated code (classes and methods) into neat semantic basic OOP principle following units is the key. nice encapsulation promotes readability and all that, but that’s for a discussion for another time.

To conclude, I’d like to issue a word of caution that’s somewhat unrelated to the post (I’ve said what I had to say), but brings up some recent memories – if someone argues that you should follow “convenience” over “convention”, you should get rid of them ASAP. They’ll corrupt your project’s codebase with their convenience code and come up with terrible ways of doing things.

Once they leave, you will have to deal with the mess they left behind and _that_ is a pain in the be-hind!

Recently, I had to upload an archive to a server which did not allow ssh. For files that I need to transfer, I just package them up in a neat archive and transfer the archive file via scp. Not having ssh access however, I uploaded the archive file via ftp and created a script which extracts the file the file looks like the following:

<?php
#extractarchive.php
echo `tar -xvfz somearchive.tar.gz`;
?>

Upon loading up “extractarchive.php”, I can see the output of the tar command through the browser. I did this by using the echo function on the backticked command line – this is not necessary for the backticked command to be executed by php.

Of course, the PHP file will need to have the necessary permissions to execute commands and as always, proceed with caution. I myself do not like doing things this way, I’ve used it in the past as a last resort. But if you ever need to do something like this, at least you know that this can be done with PHP.

The Posts I will be making in the “Classes & Examples” Sub-Category will be formatted in the following way:

• Problem: This is a short description of the problem that the PHP Class or Example will be solving.
• Class Name: The name of the PHP class.
• Responsibilities: The responsibilities of the PHP class.
• Collaborators: This lists the classes that interact with the PHP Class I will be using in the example.
• Code: What good is an example without any code?
• Considerations & Conclusion: This part of the post covers things that should be considered either when developing or using the class or code example.

As you can see, I will be trying to follow a specific format. I have some pretty big plans for this section, I hope you will find it as useful as I intend it to be.

regards.