Topic: PHP Framework Experience?

[webwhy]

I haven't built anything in PHP in more than four years.  We have a new client that only supports PHP on it's web servers, so we going to have brush up on what's going on in the PHP world.

We currently looking at a framework to embrace for the project.  We've narrowed down to three reading several comparisons on blogs.

• code igniter
• symfony
• cakephp

We built a small prototype for the client in cakephp, and no one really cared for it at all   Any of you guys have any experience with  any of these frameworks? 

Some basic criteria we're using in the evaluation:

• Robustness of ORM solution:  symfony appears to be the only framework with orm
• Proper Support for REST: at least the ability to rewrite proper urls to controllers without having to use mod_rewrite.  automatic content type negotiation would also be a huge win
• Extension framework and community marketplace for extensions
• Simplified data validation
• Scaffolding for quick admin interfaces in prototypes
• Easily testable
• Simplicity/Elegance

Any feedback would be appreciated.

[hans]

While I can't speak to a specific framework in PHP. I really like Grails, the Java/Groovy version of Rails. The simplicity and speed at which you can develop is so much better than previous frameworks I've used. Perhaps it's because I came from the Java background but I like Grails a little bit better than Rails, things just seem more intuitive for the most part.

I downloaded CakePHP to play around with and see how similar it was to Grails. The downside of Grails is that you pretty much need your own server to run things since the majority of hosts out there don't support Java for their cheap hosting.

I haven't had the time to try any of the others but I seem to recall good stuff also being said about codeigniter.

As far as I remember, CakePHP has ORM? Which version did you guys use? And what were the objections to using it? Simply coding style or you didn't like the project layout, etc?

[Steve]

Mikey is kind of the resident php expert. Ober knows it pretty well too. I know php, but no experience with framework really.

[micah]

Ober knows it pretty well too.

/understatement

[Steve]

Ober knows it pretty well too.

/understatement

probably true, just used to mike chiming in more often

[webwhy]

As far as I remember, CakePHP has ORM? Which version did you guys use? And what were the objections to using it? Simply coding style or you didn't like the project layout, etc?

we used 1.2.5-stable.  Granted we didn't have much time to completely explore the framework, we all agreed that what CakePHP referred to as ORM wasn't' good enough.  We used to building the application logic in the domain model.  Cake made this very difficult, if not impossible.  You're basically retrieving large PHP arrays from the ORM layer, there is very little incentive to develop application logic in your model.  It's totally out of phase with how we're used to working.

Another grip was how the framework worked with filters on the controller's methods.  We use these or observer classes quit a bit in our development to kick of notifications or send something to a message queue.  CakePHP's filter implementation is very basic.  We didn't really find a clean way of limiting what methods would trigger the filter's execution.  Here's a code example.

Ruby on Rails:

Code: [Select]

class ResidentialOrdersController < ApplicationController
  include MessageQueue
  after_filter :send_purchase_order, :only => :create

  def create
    # logic which creates residential order
  end
end

This is code executes a filter "send_purchase_order" after the create method on the controller is called.  The method implementation is defined in the Module MessageQueue.  This allows us to reuse our MessageQueue implementation for any controller that send a purchase order to the message queue.  We just have to include the module and tell rails what filter chain needs to call the method.  We can scope the method by adding options like :only and :except.

Here's how we had to get the same effect in cake.  Again there very well might be a better way to do this.  we don't have any experience with the framework.

Code: [Select]

class ResidentialOrdersController extends AppController
{
    function add() {
      # logic to create order here
    }

    function afterFilter() {
        parent::afterFilter();
        if($this->params['action'] == 'add') {
            $mq = new MessageQueue();
            $mq->sendMessage($this->obj);
        }
    }
}

Three major stinks here:

• The afterFilter method is overridden!  If I don't remember to call parent, we have a bug. Found this the hard way
• There's no obvious way to ensure the filter only triggers for certain actions.  we have to use a nasty if check on the parameter array.  code noise, which prevents this routine form being reused outside of its context (e.g. another controller for a different method/action
• What if I want to use this filter across several controllers?  I can cut and paste, or try to make it work with the inheritence tree.  Both are very ugly.

[hans]

We used to building the application logic in the domain model.  Cake made this very difficult, if not impossible.  You're basically retrieving large PHP arrays from the ORM layer, there is very little incentive to develop application logic in your model.  It's totally out of phase with how we're used to working.

Perhaps I'm misreading this, but that's just now an MVC framework goes. The domain (model) really shouldn't have application logic in it. That belongs in the Controller/Service classes. I think I must be missing something here, otherwise, I'm going to have to say that the Rails/Grails/Cake way of keeping application logic out of your model is a good thing.

Perhaps a workflow engine or something like Spring's Web Flow might help with your filtering stuff. Not sure if there's an equivalent feature set that can accomplish the same thing. My applications only do simple web flows which are handled right in the controller action logic (i.e. show this page or that page) and business logic is processed in a service layer (shared across controllers).

[webwhy]

Perhaps I'm misreading this, but that's just now an MVC framework goes. The domain (model) really shouldn't have application logic in it. That belongs in the Controller/Service classes. I think I must be missing something here, otherwise, I'm going to have to say that the Rails/Grails/Cake way of keeping application logic out of your model is a good thing.

nope...you read it correctly. depending on the camp you subscribe to, rich domain modeling is what you should be striving to accomplish.  service layers or 'anemic domain models' are thought of to be symptoms of poorly designed technologies (i.e. J2EE) that encouraged more procedural styles of modeling systems.  it's one of the reasons ORM tools like hibernate came to be...

http://www.martinfowler.com/bliki/AnemicDomainModel.html

[Mike]

As a general preference I don't care for frameworks too much so I can't give ya any guidance and which one to use.

[ober]

As a general preference I don't care for frameworks too much so I can't give ya any guidance and which one to use.

I'm kind of there too.  I've touched a few here and there and the most experience I've had is with the zend framework.  http://framework.zend.com/

So yeah, that gets my vote.

[Steve]

Isn't it better to use a framework then to build your own (essentially) to achieve the same thing?

[Mike]

Lets not start religious debates

[hans]

Grails isn't entirely anemic like our old Spring/Hibernate solution was, which is partly why I like Grails better. The DAO layer and validation is included in the domain class, so you get things like book.save() and book.delete() built into the object, saving precious time coding useless DAO classes. Plus, you can add other cool methods at runtime to the classes too with plugins, giving you all sort of customization ability. But that doesn't help you with PHP.

I still don't agree that business logic, like processing orders would belong in an Order class, but hey that's my current view of things. Years from now I'll look back and think how did I ever get by coding the way I am now.

That stuff aside, I'm interested in which framework you guys decide to go with since one of these days I may get back to programming PHP, although I think it's more likely I'll end up doing Ruby since it seems more and more cheap hosts are adding that to their base features.

[ober]

Lets not start religious debates

[Steve]

Lets not start religious debates

Correct me if i'm wrong (i probably am) but framework's for php is basically the same as pre-built libs for C++ right? Just predefined functions you can call on to do what you need. When i was learning OOP i used a ton of things like that. Kind of like let someone else do the hard part.