I did have a much longer reply but I don’t want anyone to get lost in details so I’ll try and keep it breif.
The assumption that view == template is imho, too simplistic. It basically removes any reusability of the display logic, because now it’s either in the controller or in the template itself. Of course this is an implementation detail but I consider the view to encapsulate the template and work above it.
I disagree with the idea views in PHP as templates are to simplistic. After all simplicity is a beautiful thing. 
In a desktop application, View logic could be quite complex. HTML removes much of the burden from us, as we no longer (as PHP programmers) need to render anything, we simply provide declarative documents, send to browser and voila. The only time presentation logic should be required (IMHO) is when deciding whether to show or hide a segment of HTML, include an additional template, etc.
I do agree that a View would encapsulate the template, Smarty is a good example of a View class (although most of us use PHP Alternative Syntax; SImple View class).
However introducing a View class for a pager. I really see views as nothing more than trivial data containers. You could provide an API I suppose, to simplify the assignment of data variables calculated by a model, such as:
$pager = new Pager_View();
$pager->setPageCount($model->getPageCount());
$pager->setPageIndex($_REQUEST[‘index’]);
$pager->setPageLength($_COOKIE[‘length’]);
echo $pager->render();
The view would have it’s template initialized in the ctor() and each method acts as simple getter/setter methods.
Having said all this, I think where we might different is in perspective.
From the point of view of a reusable pager control, it to has the triad of components, MVC.
It’s view, being a simple template. Only truly needs a few variables to render a nice pager navigation control:
- Index of active page
- Number of pages to show
From here the model could calculate the array of paging indexes to show, based on properties you might provide:
- Do you want a balanced pager, for example if you have 25 pages and you only show 5 indexes at a time and your current page is 10, do you want output to be:
8 | 9 | 10 | 11 | 12
- Do you want a simplistic pager there the active page is always the first index, from the example above:
10 | 11 | 12 | 13 | 14
The presentation logic in the template then would be checking whether to show an enabled or disabled (or whatever else)
HOME | PREV | NEXT | LAST
In this case, the model provides the API, the view remains a simple template. The model does not touch any database directly but whatever table you wanted to paginate would need a model that implemented an interface like Pager.
You could take this a step further an inject the model for the table or file listsings, etc that you wished to paginate, so using the pager, would be as simple as something like:
// Class implements a pager interface
$model = new File_Listings('../some/path');
// Injecting external model allows pager ctor()
// to initialize it's own model with required variables
$pager = new Pager($model);
$pager->setPageIndex($_REQUEST['index']);
$pager->setPageLength($_COOKIE['length']);
echo $pager->render();
If you look into many windowing frameworks that each component (ie: list box, pager, data grid, etc) they all have their own MVC components and the views are relatively simple, no calculating, complex logic, they only decide what to display, where and maybe why?
In old school applicaitons, you might have View calculations when dealing with the GDI. For instance I remember (trying) building a WYSIWYG editor and having to calculate where each character was to be positioned, adjusting line heights, etc. Working directly with the GDI this was nessecary as it did not make sense to go in the model, which would have coupled the already complex model (but possibly reusable) to the WIndows GDI API.
In PHP we do not really have that concern, the View is somewhat implied and handled for us.
I would say Views (especially complex Views) in PHP are probably a sign of over-engineering, IMO.
Cheers,
Alex
[/ot]