App Inside An App - Zend UnConn 2008

Preview:

Citation preview

An App Inside An AppMaking your Zend Framework modules distributable

(and how Doctrine can help!)

About Me:Jason Eisenmenger

Age 23

Louisville, KY

Saw the end of PHP3

This is my first talk!

What this talk covers• Making the decision

• Problems

• Solutions

• Choosing your weapons

• Doctrine

• Demonstration

Making the decisionSo you want to share your module, eh?

First and foremost:

Feature creep comes really easy.

People don’t like creeps.

Focus only on your module’s intended purpose

Problems

Dependencies

• Libraries

• Helpers / Plugins

• Base Classes

• Externals

• Methodologies

• Resources

Solution

• Include your own library

• Don’t depend on externals

• Use standard methodologies

• Allow as much configuration as possible

Integration

• Modules are secluded

Solution

• Provide an API

• Plugins

• Helpers

• View Actions

Overabundance

• Doing more than some users need/want

• Taking too much control

• Overlap of existing application

Solution

• Break it into pieces

• Allow them to be turned on / off

Point of Entry

• Requiring as little change of existing code as possible

• The simpler the better

Solution

• Bootstrap

• Controller plugin

• No entry

Boostrap

• Pros:

• Specify Prerequisites

• Access to application before dispatch

• Cons:

• Exceptions won’t be caught

• Requires excessive coding

Controller Plugin

• Pros:

• Access to application hooks

• __construct() setup same as bootstrap

• Simple: one line of code

• Cons:

• Using construct(), prerequisites depend on order of bootstrap

Other things keep in mind:

• You can’t please everybody; abstracting everything creates overhead

• Checking turned on/off features creates overhead too

Choosing your weapons

In the future:

• Zend_Tool

• Bootstrap class

• Module bootstraps

DoctrineAnd how it can help!

Before we get to the demo...

What is Doctrine?

• Doctrine is an Object Relational Mapper built to work with PHP 5.2.3 or greater.

-Wikipedia

Doctrine is organized just like Zend

How do queries work?

Turns into:SELECT `p`.`id` AS `p__id`, `p`.`user_id` AS `p__user_id`, `p`.`title` AS `p__title`, `p`.`body` AS `p__body`, `p`.`created_at` AS `p__created_at`, `p`.`updated_at` AS `p__updated_at`, `p`.`slug` AS `p__slug`, `u`.`id` AS `u__id`, `u`.`username` AS `u__username`, `u`.`password` AS `u__password`, `u`.`firstname` AS `u__firstname`, `u`.`lastname` AS `u__lastname` FROM `post` `p` INNER JOIN `user` `u` ON `p`.`user_id` = `u`.`id` ORDER BY `p`.`created_at` DESC

How are results returned?

As hydrated

arrays

How are results returned?

As hydrated objects

Saving records:

OR

Saving records with relations

How is it so smart?

• Uses “schemas” for table / relation definitions

• Builds queries accordingly

Doctrine::generateYamlFromDb()

Doctrine::generateModelsFromDb()

Doctrine::generateYamlFromModels()

Doctrine::generateModelsFromYaml()

Doctrine::generateTabelsFromModels()

Doctrine::generateSqlFromModels()

Migrations

• Tracking SQL changes manually is bad

• Migrations integrate with build processes

• Doctrine can manage them for you

Usage:

Why I chose Doctrine

• Model Generation

• Migrations

• Code reduction

• Metadata

Demo

Remember:

It’s still alpha!

The Security Module Future:

• Perhaps a full admin module

• More than just module/controller/action ACL

• Routes

• Objects / Relations

• Arbitrary user-specified

• Much more...

The ZF Project future:

• Formalized bootstrap spec or class from Zend

• Automatic module hooks

Questions:

• jasoneisen@gmail.com

• http://zfsecurity.googlecode.com

• http://framework.zend.com

• http://www.doctrine-project.org

Thank you!

Doctrine