<?php $i=1?>
                <?php query_posts('category_name=Projects2&showposts=3&orderby=rand'); ?>
                <?php while (have_posts()) : the_post(); ?>
 
                <?php if($i==1)
     {?>
      <div class="set set1">
	<div class="title"><h4><a href="<?php the_permalink();?>"><?php the_title();?></a></h4></div>
			 <div class="content"> 
                               <a href="#">
                               <?php $values = get_post_custom_values("image"); ?>
                               <img src="<?php echo $values[0]; ?>" width="242" height="148" alt="">
                               </a> 
		 <!--content end--></div>
             <!--set set1 end--></div>
 
                 <?php }
     elseif($i==2)
 {?>
                        <div class="set set1">
	<div class="title"><h4><a href="<?php the_permalink();?>"><?php the_title();?></a></h4></div>
			 <div class="content">
                                <a href="#">
                                <?php $values = get_post_custom_values("image"); ?>
                                <img src="<?php echo $values[0]; ?>" width="242" height="148" alt="">
                                </a> 
			<!--content end--></div>
                   <!--set set1 end--></div>
 
                 <?php  }
elseif($i==3)
 {?>
                        <div class="set set1">
	<div class="title"><h4><a href="<?php the_permalink();?>"><?php the_title();?></a></h4></div>
			 <div class="content">
                                <a href="#">
                                <?php $values = get_post_custom_values("image"); ?>
                                <img src="<?php echo $values[0]; ?>" width="242" height="148" alt="">
                                </a> 
			<!--content end--></div>
                   <!--set set1 end--></div>
 
                 <?php  }
     else
 {?>
                       <div class="set set1">
	<div class="title"><h4><a href="<?php the_permalink();?>"><?php the_title();?></a></h4></div>
			 <div class="content">
                                <a href="#">
                                <?php $values = get_post_custom_values("image"); ?>
                               <img src="<?php echo $values[0]; ?>" width="242" height="148" alt="">
                                </a> 
		  <!--content end--></div>
                  <!--set set1 end--></div>
 
                 <?php } ?>
 
 
                   <?php $i++; ?>
                  <?php endwhile; ?>
                  <?php wp_reset_query();?>

Into this:

<?php query_posts('category_name=Projects2&showposts=3&orderby=rand'); ?>
<?php while (have_posts()) : the_post(); ?>
 
<div class="set set1">
	 <div class="title"><h4><a href="<?php the_permalink();?>"><?php the_title();?></a></h4></div>
	 <div class="content"> 
     <a href="#">
     <?php $values = get_post_custom_values("image"); ?>
     <img src="<?php echo $values[0]; ?>" width="242" height="148" alt="">
     </a> 
  </div><!--content end-->
</div><!--set set1 end-->
 
<?php endwhile; ?>
<?php wp_reset_query();?>

Needless to say, my client will no longer be outsourcing to India.

1. The first thing, I believe, is managing your websites structure and hierarchy of pages. I don’t consider this to be the same thing as content, but it is certainly fundamental to a website. Even if your site contains some applications (a blog, a wiki, etc.), there should be a way of shoving them under this rubric, as well.
2. The next thing, of course, is managing content. Its not called a content managment system for naught, after all. Unfortunately, content is a very overloaded term. Most CMS’s seem to connect that to your site’s page structure. Create a page, throw up a WYSIWYG editor, and viola! Some CMS’s take a more fine grained approach, and consider content in a more abstract light. Content would be comparable to a data structure in a programming language. I believe ezPublish even goes as far as calling content “classes”.
3. Lastly, a CMS should be capable of creating pages which don’t fall under the rubric of your page structure directly, for example, an article section. You probably don’t want an entry in your navigation for every single article, but you definitely want a clean url like http://mydomain/articles/this-is-an-article

With that in mind, let’s talk about the “theory” of apostrophe, and how it approaches these scenarios. As far as content, apostrophe seems to have found a ground between the above mentioned approaches. On the one hand, content does not directly equal a page in your site, but can be closely associated with it. On the other hand, content is not relegated to the abstract world of boring data entry forms, but actually real live snippets of html, which can be controlled through boring data entry forms, or an rss feed, or a youtube video, or anything you want if you have some creative ideas.
With apostrophe, the we start out with the concept of a page. A page represents (almost all the time, but we’ll get to that), a public facing url on your site. Each page is backed by a slug. A page is rendered using standard php + symfony helpers. There is one layout, and each page has a template associated with it. There is no easy way, at the moment, to switch this layout, but there really shouldn’t be much of a reason why you would have to.
On the layout that comes with apostrophe, are a number of symfony slots, which are filled in at various points by apostrophe. These are generally things like menus or breadcrumbs.
Each page, has more than one “area” in it. An area is like a content holder. It can hold various types of content, stacked vertically. Each area has a name and is associated to a page. A template helper is provided to render these areas in your template.
When an area is rendered, and you are logged in with sufficient privileges, you have the ability to add content to this area. These are called slots (not to be confused with symfony slots). There are enough built in slots to put together any run-of-the-mill website fairly easily, and creating custom slots is not terribly difficult. Some of these include, plain text, rich text, video, slideshow, pdf. Each slot comes with a displayable interface (normal mode), and an editing interface (edit mode). The edit mode can be a simple form, or it can be a complex multistep, workflow-engine powered web application (see the image slot). The edit mode is powered by a component called editView. The content for the slots is, wisely, stored as a serialized php array, instead of physical columns in a database table, although the latter is certainly possible if not discouraged. This is somewhat similar to the current trend of NoSQL databases, and somewhat similar to the approach that friendfeed used when scaling their database. It would have been better, in my opinion, to store the information in JSON instead of serialized PHP, or to use an actual NoSQL database, but there is nothing stopping you from implementing your own content slots this way. When the content is not in editing mode, the display is governed by a component called normalView, where you can, of course, massage all your data as you see fit before displaying it in the components template. Each content slot is essentially a module, with two components (editView and normalView), a model class and usually a form as well. This makes it fairly trivial to create custom content slots, especially if you have prior symfony experience.
You also have the option of what is called, under the hood, a singleton area. An area which contains one and only one content slot. There is a special view helper for this as well called a_slot (as opposed to a_area).
By default, each content area is associated with the slug, and therefore the page that its on. In that respect, content and pages are somewhat analogous. For a basic site, this may well give you enough mileage to go. However, the developers realized that there is room for content which is not owned by any particular page, for example, global content. This could be an editable footer or logo which makes its way into the layout. They also recognized that not every page in a website is physically there. They call this concept “virtual pages”, and it allows for some very interesting things. Every content area, both infinite and singleton, can be assigned to a “virtual page”, and thereby pulled out in any physical page, no matter what slug it has. Virtual pages are distinguished by virtue of not have a leading “/” in their slug name, thereby removing them from the realm of the navigation. One use case I came up with, was having a sidebar in the layout, but having the content of the sidebar different for each page. In order to do this, I had to specify a slug that was guaranteed to be unique for each page, so I called it something like “sidebar-$page->id”. I will discuss another use case later.
As I mentioned earlier also, a CMS should also be able to handle pages which shouldn’t exist in your navigation, such as articles. For this, they came up with the concept of engines. Basically, instead of having your page rendered via apostrophe, it gets sent to a regular symfony module, written to certain conventions. You could have an module which renders an article page, based on an id in the url, but this page will still be under the rubric of your site. As an additional bonus, since its a regular symfony module, rendered by a regular symfony template, you can use the apostrophe helpers, and put content areas in a virtual page with a slug derived from the article’s id. This was the other use case I was referring to earlier.
This cms follows the principle of less is more, and because of that, it is a clean, elegant system, with almost no learning curve.
That is not say it does not have some problems. The admin view requires that the content areas be surrounded by a swath of DIVs. Unfortunately, these DIVs make it into the end user mode. My designer was not so happy to hear that the recommendation was to “embrace the DIVs”.
Also, the page gets loaded with a lot of incoherent, redundant, inline javascript. Both inline in the page, and sometimes inlined on the element itself. There is no Javascript framework such as what comes with diem. For example, when you click “add slot” in an area, you are greeting with a very eye-appealing dropdown box. Unfortunately, to mimic that behavior seems to require a lot of copy and pasting.
Certain areas of the code also look suspect and “hackish” to me. Any class named “aTools” with only static methods is certainly a red flag. Of course, symfony 1.x also has code like this as well, but that doesn’t mean that bad habits should be copied. Virtual pages are implemented, by temporarily switching a global variable (disguised a static variable), which holds the current page’s slug, for the duration of the rendering, until when the global variable is swapped back to its original state. This feels like hacky code to me.
Over all, I have to certainly commend the developers of apostrophe. They managed to come up with good solutions for some classic problems in web development. They managed to create a tool which is good for end users *and* developers at the same time. Certainly not an easy task.

/**
 * CodeIgniter Application Controller Class
 *
 * This class object is the super class the every library in
 * CodeIgniter will be assigned to.

Of course this is really CodeIgniter’s problem I guess, but it certainly bleeds into EE. This is called a God object, and is one of the oldest anti-patterns in the book. No more global variables they say? Gone is global $TMPL. Long live $this->EE->TMPL! What about dependency injection? We’re almost in 2010 for god sakes. This reminds me of the “let’s get rid of globals but making a bunch of singleton and static classes…now we’re doing OOP, yeah!” argument.
At least the template class can be used, more or less, “outside” of EE templates, but so far that’s the only “api” improvement I could find. They haven’t gotten rid of such garbage such as “action_ids”. The database is still retarded. Not only are they storing settings in the database, they’re now encoding them in base64! Where did that come from?.

Ultimately, I am utterly disappointed, and EE is becoming less and less of a platform to build applications off of.

<form action="<?=$this->element->getAction()?>">
<?=$this->element->name->renderViewHelper()?>
</form>

In a form ViewScript, just output that directly into your viewscript!

<form action="<?=$this->form->getAction()?>">
<?=$this->form->name->renderViewHelper()?>
</form>

If you want the script to be reusable, just use the render viewhelper, as recommended in the performance guide.

Let’s take a classic procedural app, like…I don’t know…Wordpress.

The wordpress API has a function wp_authenticate_username_password, which will authenticate a user, with a given username and password. So, if you had an app which you wanted to connect with Wordpress (or maybe write some kind of extension or plugin), you can easily make use of this API. It’s very easy to understand, and there’s nothing inherently wrong with it.

Let’s translate this to Zend_Auth. Or to be more accurate, to Zend_Auth_Adapter_Interface:

public function authenticateAction() {
    //Set up adapter
    $adapter->setIdentity($identity);
    $adapter->setCredential($credential);
    $result = $this->adapter->authenticate();
    //Do other stuff
}

Look’s good right? We’re using an object (Zend_Auth_Adapter_Interface), in an object (LoginController), and returning an object (Zend_Auth_Result). What can be more “Object Oriented” about that?

For a long time this smelled to me, and I couldn’t stand looking at my auth controller. I knew there had to be a better way. So after a lot of thought, pondering, reading, and inspiration, this is what I’ve come with.

The first thing to notice is that all we’ve done was call bunch of methods. These could have easily been static methods, or even global functions like in Wordpress’s API. The second sin here, is all these calls make our controller nice and fat. To make matters worse, it makes it hard to reuse this authentication logic somewhere else. Imagine if you were writing a CMS, and somebody wanted to write an extension, using your API (try authenticating a user using Expression Engine’s “API”).

What did we really want to do though? Authenticate a user of course.

How about something like this?

public function authenticateAction($user = null) {
     if ($user === null) { 
          //somehow get the user, probably from a form submission...
     }     
     $result = $user->authenticate($authenticationService);
 
     if ($result->isValid()) {
         $user->login($authenticationService);
     }
}

Here we are delegating our business to logic to the…um…business layer. There are other advantages here, though. The user class doesn’t have to spill his beans to the controller, in keeping with the principle of tell don’t ask.
So what are the bits and pieces here?
The first is obvious…the user class. That just needs a reference to an authenticator. So what is an authenticator? It could be as simple as passing in an instance of Zend_Auth_Adapter_Interface.
But I like to go one level more abstract, and create my own interface for authentication. My default implementation will be a ZendAuthenticator. To make things simple, my implementation will have a hard dependency on Zend_Auth_Adapter_DbTable, and not on the interface for the adapter. I have a couple of reasons for this: 90% of all web apps authenticate a database. The chances of them switching to something else, are not high. Certainly not mine.
Also, in general I don’t like the Zend_Auth_Adapter_Interface. It seems to me that it violates one of Misko’s rules that injectables can depend on injectables, and newables can depend on newables, but the twain shall not mix.
So if my understanding of that rule is correct, $adapter->setIdentity($thisvarisanewable), would be a violation of the rule. And indeed, you can see that to switch adapters would be a big pain. Each adapter is required to be “setup” before calling its authenticate method, and they have wildly different APIs. (Of course, I’ve been trying to think all day how they can all be unified better, and I appreciate that it’s not an easy thing. So let’s just keep it simple (ok, not that simple)).
So my interface looks something like this:

interface Authenticator {
    /* @returns Zend_Auth_Result */
    public function authenticate($username, $password);
    public function login($identity);
}

I split up login and identity, because it entirely desirable at some point to log in a user without having to authenticate him (think “log in as user” for an admin).

(I’ve been back and forth on whether these should really be two different classes, since there are two responsibilities here, if anybody has some recommendations.)

My implementation looks something like this:

class ZendAuthenticator implements IAuthenticator {
	private $adapter;
 
	public function __construct(Zend_Auth_Adapter_DbTable $adapter) {
		$this->adapter = $adapter;
	}
 
	public function authenticate($identity,$credential) {
		$this->adapter->setIdentity($identity);
		$this->adapter->setCredential($credential);
 
		return $this->adapter->authenticate();
	}
 
	public function login($identity) {
		Zend_Auth::getInstance()->getStorage()->write($identity);
		return Zend_Auth::getInstance()->getIdentity();
	}
}

(Another point to think about here: ignoring Zend_Auth completely, and just using Zend_Session_Namespace. I’m not sure exactly what Zend_Auth is gaining me here. It seems like the real gain here is from the adapter.)

Now my controller doesn’t smell as bad, and is much more of a pleasure to look at.