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

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.

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.

To display only the contents of the view on the page without being framed by a template, the tmpl variable needs to be set to “component”.

Something along the lines of having the following snippet in the controller method:
JRequest::setVar(‘tmpl’, ‘component’);

Either that, or adding “&tmpl=component” to the URL.

I remember doing it before, however it’s been a while.

All attempts at searching on how to do the above proved frustratingly impossible as the organic search results for google are filled with people asking how to “disable legacy” modes, “templates”, “modules”, “plugins”, how to make your joomla admin panel rock(!!!!) – not what I was looking for!

Anyway, it’s a rather simple, but not particulary obvious thing – I had to track down the code which I had written over 6 months ago to track that snippet down.

Hope this helps other Joomla! component developers

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

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