Tek-X: A Framework for People who Hate Frameworks - Lithium

A Framework for People
Who Hate Frameworks.

Find us on :
http://joind.in/1592

A movement in 3 parts

• Frameworks suck
• Everything you know is wrong
• Lithium tries to suck less

Let’s get one thing out
of the way:

Because your
framework sucks, too.

Why?
(Besides the obvious attempt at being provocative)

Frameworks Suck

• Code you will never use.

Frameworks Suck

• Complexity overhead.

Frameworks Suck

• Complexity overhead.
• You didn’t write it.

His name is the
biggest, so it’s his
fault.

We’re not saying design patterns are bad.
Quite the opposite.

Lithium implements many design patterns.

Some patterns only treat the symptoms,
instead of the cause.

Object dependencies.
“The principle of separating configuration from use.”

[CakePHP code]

function initialize(&$controller, $settings = array()) {
/* ...[snip]... */

$prefixes = Router::prefixes();
if (!empty($prefixes)) {
foreach ($prefixes as $prefix) {
/* ...[do something nasty to the global state]... */
}
}
if (Configure::read() > 0) {
App::import('Debugger');
Debugger::checkSecurityKeys();
}
}

Sucks.
/* ...[snip]... */

}
}
}
}

Sucks.
/* ...[snip]... */

}
}
}
}

Sucks hard.

Sometimes in the same framework.

Sucks
function spam($emails) {

$this->Email->replyTo = 'nigerian.prince@example.com';
$this->Email->from = 'Desmond Etete <nigerian.prince@example.com>';
$this->Email->template = 'mo_monies';
$this->Email->sendAs = 'annoying_html';

foreach ($emails as $email) {
$this->Email->to = $email['address'];
$this->Email->subject = "Good to you news I have {$email['name']}";
$this->Email->send();
}
}

[variables changed to protect the innocent.]

[variables changed to protect the innocent.]
[... not really. It’s Symfony.]

class User {
function __construct($storage) {
$this->storage = $storage;
}
}

$storage = new SessionStorage('SESSION_ID');
$user = new User($storage);

Show that object who’s boss.
class User {
function __construct($storage) {
$this->storage = $storage;
}
}

$storage = new SessionStorage('SESSION_ID');
$user = new User($storage);

Of course, we want this to abstract this.

Frameworks adore abstractions.

class Container {
static protected $shared = array();
// ...

public function getMailer() {
if (isset(self::$shared['mailer'])) {
return self::$shared['mailer'];
}

$class = $this->parameters['mailer.class'];
$mailer = new $class();
$mailer->setDefaultTransport($this->getMailTransport());

return self::$shared['mailer'] = $mailer;
}
}

But now you want an abstraction to manage
the DI container.

Duh.

So you create a “Service Container”.

class Container extends sfServiceContainer {
static protected $shared = array();

protected function getMailTransportService() {
return new Zend_Mail_Transport_Smtp('smtp.gmail.com', array(
'auth' => 'login',
'username' => $this['mailer.username'],
'password' => $this['mailer.password'],
'ssl' => 'ssl',
'port' => 465,
));
}
}

Of course, we now want to abstract the
crap out of the Service Container.

Double duh.

So lets use a Builder to configure the
Services.

Yeah!
require_once '/PATH/TO/sfServiceContainerAutoloader.php';
sfServiceContainerAutoloader::register();

$sc = new sfServiceContainerBuilder();

$sc->
register('mail.transport', 'Zend_Mail_Transport_Smtp')->
addArgument('smtp.gmail.com')->
addArgument(array(
'auth' => 'login',
'username' => '%mailer.username%',
'password' => '%mailer.password%',
'ssl' => 'ssl',
'port' => 465,
))->
setShared(false)
;

$sc->
register('mailer', '%mailer.class%')->
addMethodCall('setDefaultTransport', array(new sfServiceReference('mail.transport')))
;

And for good measure, have our configurations
for Service Containers in XML files.

So....
We have Dependency Injection.

So....
Managed by a Service Container.

So....
Parametrized with XML data.

So....
And the whole thing configured by a Builder.

So....
And the whole thing configured by a Builder.

...to fix one problem.

Anyone see what’s wrong here?

Many of these patterns were implemented in
Java, to solve language problems that PHP just
doesn’t have.

The sun does not
revolve around OOP

Galileo facing the Roman Inquistion
- Cristiano Banti (1857)

The sun does not
revolve around OOP
...nevertheless,
it moves.

Galileo facing the Roman Inquistion
- Cristiano Banti (1857)

class User {

public function create() {
$logger = new Logger();
$logger->write('Creating a new user...');

$this->_doSomeInitialization();
$this->_databaseConnection->doATransaction($this)->create();

$logger->write('Finished creating user');
}
}

$user = new User();
$user->create();

Dependency Injection
• Fixes the problem of static dependencies

• Ignores the problem of static relationships

• Same methods called on injected classes

• No way to introduce new relationships

• No way to introduce new relationships
• Higher overhead, more boilerplate code

class Service extends lithiumcoreObject {

protected $_classes = array(
'request' => 'lithiumnethttpRequest',
'response' => 'lithiumnethttpResponse',
'socket' => 'lithiumnetsocketContext'
);

protected function _init() {
$class = Libraries::locate('socket.util', $this->_classes['socket']);
$this->_connection = new $class($this->_config);
// ...
}

/* ...[snip]... */

public function send($method, $path = null, $data = null, array $options = array()) {
/* ...[snip]... */
$response = $this->_connection->send($request, array('classes' => $this->_classes));
// ...
}
}

Coupling should be in
proportion to domain
relevance.

If...
Configure::write('debug', 0);

If...

is evil,

If...

is evil,
$this->debug = 0;

If...

is evil,
$this->debug = 0;

is the

class Service {

protected $_timeout = 30;

public function send($method, $data = null, array $options = array()) {

// WTF does this do?
$this->_prepare();

$response = $this->_connection->send($request, array(
'timeout' => $this->_timeout
));
// ...
}
}

OO doesn’t make you
think (about state).

ActiveRecord
Data Access Object

Unit of Work
Registry

Front Controller MVC

Value Object
Data Mapper Service Layer

Design patterns
• Each pattern is only useful in a limited
context

Design patterns
context

• Layering many design patterns on top of
each other often indicates poor design
choices

Design patterns
context

• Layering many design patterns on top of
each other often indicates poor design
choices

• Mis-application arises from trying to run
before you can walk

Tools do not mean...

...you can build a house.

Aspect-Oriented Design
• Separation of concerns

• Domain classes should not know or care about cross-
cutting concerns

cutting concerns

• Examples:

cutting concerns

• Examples:
• Caching

cutting concerns

• Examples:
• Caching
• Logging

cutting concerns

• Examples:
• Caching
• Logging
• Access Control, etc.

Functional Programming

• Only possible when functions are first-class
citizens


citizens

• Referential transparency


citizens

• Referential transparency
• Function purity

Referential transparency is not...

Referential transparency is not...

$this date()

$_*

These Are Not
Design Patterns.

Less Suck
• Draws on years of experience building web
frameworks

Less Suck
frameworks

• PHP 5.3+ only

Less Suck
frameworks

• PHP 5.3+ only
• Doesn’t assume you’re stupid

<?php

namespace applicationbar;

use lithiumutilString;
use lithiumutilCollection;

class Foo extends lithiumcoreObject {

'cache' => 'lithiumstorageCache',
'logger' => 'lithiumanalysisLogger'
);

public function __construct(array $config = array()) {
// ...
}

// ...
}
}

?>

public function __construct(array $config = array())
<?php


use public function __construct(array $config = array())
lithiumutilString;
public function'lithiumstorageCache', = array())
'cache' => __construct(array $config
);

// ...
}

// ...
}
}
?>

<?php
<?php

class Foo extends lithiumcoreObject
use lithiumutilString; {
$or = $some->highOverHead($operation);
$or()->otherwise(HARD_TO_TEST)->code();
}
}
);

?>
// ...
}

protected function _init() { 2
// ...
}
}

?>

<?php
<?php

class Foo extends lithiumcoreObject
use lithiumutilString; {
$or = $some->highOverHead($operation);
$or()->otherwise(HARD_TO_TEST)->code();
}
}
);

?>
// ...
}

protected function _init() { 2
// ...
}
}
$foo = new Foo(array('init' => false));
?>

<?php

3
new applicationbarFoo();
// loads app/bar/Foo.php

);

// ...
}

// ...
}
}

?>

<?php


4


);

// ...
}

// ...
}
}

?>

<?php




5
);

// ...
}

// ... = $this->_classes['cache'];
$cache
} $cache::write(__CLASS__, $this->_someGeneratedValue());
} }
}
?>
?>

<?php




5
);

$foo = new Foo(array('classes' => array(
'cache' => 'applicationextensionsCache'
// ...
)));
}

$cache
} }
}
?>
?>

<?php




);

// ...
}

$cache
} }
}
?>
?>

Keeps parameter lists short
&
Makes class APIs more extensible

Same idea. But...!
Modifies class / object state.

Adaptable

Auth

Cache

Catalog

Connections

Logger

Session

use lithiumsecurityAuth;

Auth::config(array(
'customer' => array(
'adapter' => 'Form',
'model' => 'Customer',
'fields' => array('email', 'password')
)
));

use lithiumstorageCache;

Cache::config(array(
'local' => array('adapter' => 'Apc'),
'distributed' => array(
'adapter' => 'Memcached',
'servers' => array('127.0.0.1', 11211),
),
'default' => array('adapter' => 'File')
));

use lithiumdataConnections;

Connections::config(array(
'old' => array(
'type' => 'database',
'adapter' => 'MySql',
'user' => 'bobby_tables',
'password' => '******',
'database' => 'my_app'
),
'new' => array(
'type' => 'MongoDb',
'database' => 'my_app'
)
));

use lithiumstorageSession;

Session::config(array(
'cookie' => array(
'adapter' => 'Cookie',
'expire' => '+2 days'
),
'default' => array('adapter' => 'Php')
));


'default' => array(
'adapter' => 'MyCustomAdapter',
'expires' => '+2 days',
'custom' => 'Whatevah!'
)
));

use lithiumstorageCache;

Cache::config(array(
'default' => array(
'development' => array(
'adapter' => 'Apc'
),
'production' => array(
'adapter' => 'Memcached',
'servers' => array('127.0.0.1', 11211)
)
)
));

Works identically for all adapters.

If you remember nothing
else about configuration
state...

Immutability.
Set it and forget it.

Zoom?
• Performance vs. speed of development is a
series of trade-offs

Zoom?

• Large-scale apps don’t use stock framework
infrastructure, and that’s a good thing

Zoom?

• Large-scale apps don’t use stock framework
infrastructure, and that’s a good thing

• A generalized framework will never be as
fast as hand-tuned code

Zoom!
• Choice is good
• Use native extensions (PECL) whenever
possible.

Zoom!
• Choice is good
possible.

• Don’t like a class? Change it. At runtime.

Zoom!
• Choice is good
possible.

• Don’t like a class? Change it. At runtime.
• Profiled at every step of the way.

use appmodelsPost;
use lithiumactionResponse;
use lithiumnethttpRouter;

Router::connect('/frequent_api_call.json', array(), function($request) {
return new Response(array(
'type' => 'application/json',
'body' => Post::recent()->to('json')
));
});

Lithium is the most
flexible framework.
(yeah, we said it)

Most class dependencies
are dynamic.

class Service extends lithiumcoreObject {

'request' => 'lithiumnethttpRequest',
'response' => 'lithiumnethttpResponse',
'socket' => 'lithiumnetsocketContext'
);
}

$service = new Service(array('classes' => array(
'socket' => 'mycustomSocket'
)));

The Filter System:
for PHP.

Example: Caching & Logging

Post::ﬁnd()


Logging

Post::ﬁnd()


Caching

Logging

Post::ﬁnd()

use lithiumanalysisLogger;

Post::applyFilter('find', function($self, $params, $chain) {
// Generate the log message
$conditions = $params['options']['conditions'];
$message = 'Post query with constraint ' . var_export($conditions, true);

Logger::write('info', $message);
return $chain->next($self, $params, $chain);
});

use lithiumanalysisLogger;

Post Logger
Post::applyFilter('find', function($self, $params, $chain) {
// Generate the log message
$conditions = $params['options']['conditions'];
$message = 'Post query with constraint ' . var_export($conditions, true);

Logger::write('info', $message);
return $chain->next($self, $params, $chain);
});

What about Observer?

• Dependent on a centralized publish/
subscribe system


subscribe system

• Extra layer of abstraction


subscribe system

• Extra layer of abstraction
• Fewer possibilities


• Filters are self-contained and attach
directly to objects


• Filters are self-contained and attach
directly to objects

• Direct and intuitive

Features: Everything is an adapter.

(well, almost)

Databases
• 1st-class support for document-oriented
databases

• MongoDB & CouchDB: production ready
• Relational databases in beta
• Cassandra in the works, too

<?php

$post = Post::create(array(
'title' => 'Ein bier, bitte',
'body' => 'Was ist los mit dir?'
));
$post->save();

$post = Post::find($id);

?>

<h2><?=$post->title; ?></h2>
<p><?=$post->body; ?></p>

This works on...

• MongoDB
• CouchDB

This works on...

• MongoDB
• CouchDB
• MySQL

This works on...

• MongoDB
• CouchDB
• MySQL
• SQLite (almost)

MongoDB + CouchDB:
$post = Post::create(array(
'title' => 'Ein bier, bitte',
'body' => 'Was ist los mit dir?',
'tags' => array('PHP', 'Bier'),
'author' => array('name' => 'Nate')
));

$post->save();

MongoDB:
$posts = Post::all(array('conditions' => array(
'tags' => array('PHP', 'Bier'),
'author.name' => 'Nate'
)));

// Translates to...
db.posts.find({
tags : { $in : ['PHP', 'Bier'] },
'author.name' : 'Nate'
})

Databases

• Adapter based, plugin aware
• Will ship with MySQL, SQLite
• SQL Server support via plugin
• Query API

The Query API

• Flexible data container
• Allows each backend data store to only worry
about features it implements

• Keeps model API separate from backend data
sources

The Query API

$ages = User::all(array(
'group' => 'age',
'reduce' => 'function(obj, prev) { prev.count++; }',
'initial' => array('count' => 0)
));

The Query API
$query = new Query(array(
'type' => 'read',
'model' => 'appmodelsPost',
'fields' => array('Post.title', 'Post.body'),
'conditions' => array('Post.id' => new Query(array(
'type' => 'read',
'fields' => array('post_id'),
'model' => 'appmodelsTagging',
'conditions' => array('Tag.name' => array('foo', 'bar', 'baz')),
)))
));

The Query API

• Run simple queries via the Model API
• Build your own complex queries with the
Query API

• Create your own adapter, or drop in a
custom query optimizer

Plays nice with others

• Easily load & use libraries from other
frameworks:

• Zend Framework, Solar, Symfony, PEAR,
etc.

• PSR-0 Class-loading standard

/* add the trunk */
Libraries::add("Zend", array(
"prefix" => "Zend_",
"includePath" => true,
"bootstrap" => "Loader/Autoloader.php",
"loader" => array("Zend_Loader_Autoloader", "autoload"),
"transform" => function($class) { return str_replace("_", "/", $class) . ".php"; }
));

/* add the incubator */
Libraries::add("Zend_Incubator", array(
"prefix" => "Zend_",
"includePath" => '/htdocs/libraries/Zend/incubator/library',
"transform" => function($class) { return str_replace("_", "/", $class) . ".php"; }
));

namespace appcontrollers;

use Zend_Mail_Storage_Pop3;

class EmailController extends lithiumactionController {

public function index() {
$mail = new Zend_Mail_Storage_Pop3(array(
'host' => 'localhost', 'user' => 'test', 'password' => 'test'
));
return compact('mail');
}

}

This has been a presentation by:

Nate Abele (@nateabele)

Joël Perras (@jperras)

Sucks. But check it out anyway.

Tek-X: A Framework for People who Hate Frameworks - Lithium

Recomendados

Recomendados

Más contenido relacionado

Último

Último (20)

Destacado

Destacado (20)

Tek-X: A Framework for People who Hate Frameworks - Lithium

Notas del editor