Here’s a quick SVN trick I use for managing my svn:ignore and svn:externals properties for my projects.

One of the first things I do for newly checked out projects is to add a externals.txt and ignore.txt files. Then I just populate these with the property values I require for the project.

I know, it’s a no brainer when you think about it right?

The thing is, I didn’t think of doing it until the past few projects and actually had to rely on ide integrated / gui tools to do it prior to this year. I came across a couple of examples and did it a couple of times in a rush without noting it down, but thought I’d make a post about it on my blog so that I have somehwere easy to find.

Here’s a quick example:

example contents of externals.txt

library/Zend http://framework.zend.com/svn/framework/standard/tags/release-1.10.4/library/Zend
library/ZendX http://framework.zend.com/svn/framework/standard/tags/release-1.10.4/extras/library/ZendX/
library/Doctrine http://svn.doctrine-project.org/tags/1.2.2/lib/Doctrine
externals/dojo http://svn.dojotoolkit.org/src/branches/1.4
nbproject

example contents of ignore.txt

public/webalizer
public/analog

Then I use the -F arguement to specify that I want to use the contents of a file to specify the value or values of the property.
$ svn propset svn:ignore -F ignore.txt . to set my svn:ignore property values.
or
$ svn propset svn:externals -F externals.txt . to set my svn:externals property values.

It’s all about convenience baby!

This makes svn properties management very convenient. It’s one of the things that make it easier for me to set things up. What’s more, when I need to add or remove to/from svn:externals or svn:ignore, I can do so easily – managing my svn properties this way, I also have a good reference as to what my property values are without having to run a number of svn propgets via command line.

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 –>

I, on the other hand, did nothing but take and take – even to this point – so now I decided that one way to give back was to write a post on how to set up the Zend Framework complete with a model layer that I am going to be proposing. This should be interesting seeing as I’ve only _just_ managed to implement a Model Service layer which uses Doctrine ORM as a means to connect to the database.

I’ll also provide source code and will host it on github or google. What I found was that even though there was a lot of resources out there on how to integrate Zend Frameowk, Doctrine and PHPUnit on your devbox, some were a little out dated and some were a little unclear leaving me to feel my way around.

SO what I’m going to try and do is write something that can be used as a skeleton for anyone who may want to just knuckle down and hit the ground running. Not that you can’t already with the current Zend QuickStart, but I don’t think that I’m the only one who had problems getting this all to work so my target audience for this type blog post series are developers who have just discovered Zend Framework, Doctrine and Unit Testing and would like to have some references to poke around.

I guess that’s my thing for today. I’ll spend some hours on making sure it’s comprehensive enough to use as a how-to and present solutions on how I got around certain things such as the prerequisite to have Aggressive Model Autoloading for doctrine when in the Unit Testing Command line which uses Doctrine-CLI to refresh tables etc.

It won’t be tomorrow, but it will be done during the following weeks. I’ll be in touch.

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

I must admit – I thought I had made a break through, but alas, more analysis paralysis.

I’m finding that I’m abusing the accessiblity of the Service Layer.

Here’s an example:

• I’ve got an application which manages users.
• I have a User Model and have User Service as the pivot point where application logic gets ported to to business logic.

The User Service class provides the following functionality:

• CRUD (Create, Read, Update and Delete) which pretty much proxies to the Model.
• Also, the Service layer looks after Authentications
• and Authorisation.

All pretty straight forward, at this point. Of course you’ll also have:

• A Form factory in the UserService class as well as
• a List method which returns an assoc array of mutiple results based on criteria.

However, what would you do in situations where the client has requested for the Ability to update several records via a CSV import.

I thought hey, ok, I’ll:

• Add a “get Upload Update File” form…
• Then I’ll add an “Upload Method” to process the upload,
• I need to delete this file also – now I’ll add a “delete file” method,
• More thinking brought on I need to centralise file name creation so that ensure that I am only using one name.
• I’m using a csvreadstore to read the csv file for review – so I need to have a “readstore” method for the csv file.
• I’ll also need to validate this file
• FInally, I need to massage the data from the CSV into my domain model and either update one by one by one or update it all as a big group.

But this will leave me with an extremely heavy service layer and a somewhat thin Model object.

I don’t know what to do – I can do it both ways, but it’s just not blatantly clear as to which direction I should be pushing this to.

What would you do as an OOP programmer? Can you crack this little dillema I’m having? Am I heading in the right direction? Should I create a new Service layer called UpdateUsersService (which of course seems like a bad idea to me).

I’m open to feedback – where do you think I should go?

With Doctrine doing a _lot_ of magic, I thought that this would be something that I wanted to see for myself.

4MB Memory to execute a simple Query?!?! Ffffff#$#!!!!

A quick google search took me to a Question posted on StackOverflow about Doctrine Memory Usage. The concerned OP was asking if he had a server misconfiguration or if this was normal for Doctrine to be using so much memory for a simple query. He posted a 4MB difference in Peak Memory Usage between the start of the request before the Doctrine Query was executed and after the Doctrine Query was executed. After reading that, I was a little nervous.

Use Opcode Caching to reduce Memory Usage.

There were a couple of answers and comments one of the answers came from Doctrine’s own romanb (I think?) specifying that you _need_ opcode caching if you’re going to be using something the size of Doctrine (and Zend Framework for that matter).

Similar to what the OP at StackOverflow did, I created a simple test which measures peak memory usage when using Doctrine from within the Zend Framework.

Be warned however, that this is not a real benchmark. All this is testing is what memory usage is using the simplest of simplest operations. In this case, I created a query which pulls one record from the Database.

Here are the details.

The Controller I used for this quick test:

<?php

class IndexController
extends Zend_Controller_Action
{
// with doctrine set up and everything
/**
*
* @return unknown_type
*/
public function memoryUsageTestAction()
{
$this->_echo_memory_usage();
$q = Doctrine_Query::create()
->from(‘Default_Model_User u’)
->where(‘u.ID = ?’, 1);

$result = $q->fetchOne();
echo $result['FirstName'] . ‘ ‘ .$result['LastName']. ‘<br />’;

$this->_echo_memory_usage();
exit;
}

/**
* Function from: http://www.php.net/manual/en/function.memory-get-usage.php
* @return unknown_type
*/
protected function _echo_memory_usage() {
$mem_usage = memory_get_usage(true);

if ($mem_usage < 1024)
echo $mem_usage.” bytes”;
elseif ($mem_usage < 1048576)
echo round($mem_usage/1024,2).” kilobytes”;
else
echo round($mem_usage/1048576,2).” megabytes”;
echo “<br/>”;
}
}

Result without APC:

10.25 megabytes
RV David
16.5 megabytes

Result with APC:

3 megabytes
RV David
4.25 megabytes

This is with the following APC configuration:

apc.shm_size = 30
apc.ttl = 7200
apc.user_ttl = 7200
apc.mmap_file_mask = /tmp/apc.XXXXXX

apc.shm_segments = 1
apc.optimization = 0
apc.num_files_hint = 1000

As you can see, there’s a big difference – chopped ZF Memory Peak Usage (my configuration anyway) by about 65%-70% and Peak Usage with a Doctrine call to the Database by about 75%.

That was the lack of decoupling of my Model layer from the View and Controller layers of my MVC projects. Don’t get me wrong, the applications we’ve written work and work well, but the perfectionist in me simply just refuses to stop trying to mentally refactor old projects.

From the time I had first conceptualised the our in-house MVC framework: Cubix and this is before switching to Zend, something that has left me in Analysis paralysis is the Model layer.

I mean, most things I’ve read usually mention the Model layer as a representation of your applications business logic, but this is left wide open to interpretation. The difficult thing here is, that because the business logic is so specific to projects, there’s no real way of explaining it aside from some really basic examples which turn out to be the equivallent of a Javascript example of: “Hello World.”

Not very useful, examples leave a lot of details out – because there’s no real way of dishing out a good example. Even the Zend Framework’s guestbook example in their Quickstart is a little thin.

Starting my research, I googled the term zend framework model tutorial and one of the entries that piqued my interest was a post by brandon from realm of zod titled: Domain Model Programming With the Zend Framework which talks about using Doctrine ORM instead of Zend DB Table‘s Table Data Gateway implementation.

I wasn’t so interested in Doctrine, so I just skimmed past the examples, but he did mention a few links, one link was to Matthew Weier O’Phinney’s blog post on Model Infrastructure – here, Matthew talks about the implementation of the Domain Model Design Pattern and talks about having a Gateway to the Domain using the Gateway pattern from Martin Fowler’s PoEAA (ok – you get the picture, I’ll stop hyper linking).

I thought: Great! So we use the Domain Model Design Pattern (as the model layer) to represent business logic, then create an access point or gateway if you will with a simple API that the model’s client’s can use to make the model do it’s thing!

As oppsed to to how I used to do it which is use the model class as the access point for Business Data and Process.

I browsed through the comments, past all the questions and onto comment #34 where the commen(ta?)tor asks about why shouldn’t we just stick domain login in Zend_Db_Table_Row_Abstract and how muddying the Domain Model by making it aware of the persistence layer (I’m guessing this means database) is equally wrong – why we shouldn’t extend Zend_Db_Table_Row_Abstract is a given, but I thought that he did have a point when he mentioned that persistence and business logic is just as bad.

Enter the Service Layer

Poster #34 added a link to Angry Objects’ one and only blog post: Writing Robust PHP Backends with Zend Framework and just like that, it was clear. This is what I’ve been looking for all this time! Or so it seemed!

Exit the Bloated Service Layer: The Method Described above is actually an Anti-pattern.

Further research then reveals that almost everything mentioned on Angry Object’s post, is what Martin Fowler talks about in 2003 on his Bliki: The Anemic Domain Model anti-pattern.

What should happen now then?

Well the night wasn’t all a loss – the Anemic Domain Model Anti-Pattern page on Martin Fowler’s Bliki actually explains what your Domain Models and what Service Layers are actually for.

So armed with this knowledge, I’ll march forward and develop my next project using the Domain Model with a thin Service Layer – similar, if not identical to, what Matthew was talking about on his blog post on Model Infrastructure) as I go through this and if I find some more free time, I might post some code samples of how I’m going.

And so wraps up yet another night of R&D – Interesting though, thought I had this licked. At least now, I have a few ideas as to which path to take. I’ll be downloading Matthews pastebin app to get some sample source code – should be interesting.

This took some time to actually get my head around, but I have managed to “will” this solution into existance. I say “will” because i’m not too happy with the implementation. It’s a workaround that works for the mean time anyway.

I’ve written the description here on the “DevProducts on Blogger” blog – Check out the post for more info: Persistent Column Widths in Dojo (dojox) DataGrids