Zend Framework MVC driven ExtJS

Zend Framework MVC driven ExtJS

Thorsten Suckow-Homberg, K&K GmbH

Sourc{ - SenchaDev Conference
May 5-7, 2011
Croatia, Split

Who am I?

● Thorsten Suckow-Homberg
● Born 1976, Aachen, Germany
● Webdeveloper since 1999
● Senior Software Developer for K&K GmbH,
Aachen
● Focus on planning, architecture and
deployment of web based software

Who am I?

… oh, and UI programming, of course:
Author of:
● conjoon – http://www.conjoon.org
● Ext.ux.Livegrid – http://www.ext-livegrid.com
● various other open source ExtJS extensions/
components
● Numerous bug reports, rants and proposals over at
the sencha forums :) (MindPatterns)

This talk will show you...

● … how you should plan your directory layout in
larger projects


larger projects
● … what is application context - and how to use
it to your advantage


larger projects
● … how to use Ext.Direct with existing ZF
backend code


larger projects
● … how to use Ext.Direct with existing ZF
backend code
● In short: ...why Zend Framework could become
the framework of your choice when combining
Ext and PHP

The Basics

Directory Layout

The Basics – Directory Layout
● Top level should be a
directory named after your
project (obviously)
● ...containing three child
directories:

build-tools
● Real tools, like:
● yuicompressor
● phing
● ant

build-tools
● Real tools, like:
● yuicompressor
● phing
● ant
● (XML-)build scripts
● code sanity
● tests
● deployment
● etc... in short: Continuous
Integration[1]!

vendor
● All the third party libs
you're using in your code
● ExtJS
● ZendFramework
● etc.

vendor
● All the third party libs
you're using in your code
● ExtJS
● ZendFramework
● etc.

Note:
● files from separate repository vendor branch will be
merged into this directory
● Best case: developers will not touch the vendor directory
● Read [2] for more infos on how to use vendor branches


src


src
● Everything you're actually
coding


src
● Everything you're actually
coding:
● overrides
● extensions
● backend code
● code that might refer to
vendor code
● … in short: all
application-specific
code your team writes

corelib

corelib
● js – your client libraries
(ExtJS, own
implementations)

corelib
● js – your client libraries
(ExtJS, own
implementations)
● php – your backend
code (including tests)

datastore
● data storage
definition/structure goes
here

datastore
● data storage
definition/structure goes
here

Note:
● build scripts can refer to the structure file when deploying
an application

www
● one step more towards
a „callable“ application

application

application
● ZF specific „frontend“
code (controllers,
templates)

application
● ZF specific „frontend“
code (controllers,
templates)
● and:
– Meta-Information
files for your
application
– caching directories
– etc.

htdocs

htdocs
● Finally! The document
root for your application
● the only „public“ folder

htdocs
● Finally! The document
root for your application
● the only „public“ folder

Note:
● Build-process focuses on this folder

„This layout gets way too
complex!“

Don't go berserk!

There's a solution to all of
it!

„Do I need to run a build
process every time a line
of code changed?“

„How do I get the
resources from vendor into
my src folder where –
obviously - running code
will resist?“

working copy (development):
/var/www/your_project/vendor/ext-ux-util-messagebus
/var/www/your_project/src/www/htdocs/index.php


<?php if ($isDeployment) { ?>
<script type="text/javascript" src="/js/ext-ux-util-messagebus/src/messagebus.js"></script>
<?php } else { ?>
<script type="text/javascript" src="/vendor/ext-ux-util-messagebus/src/messagebus.js"></script>
<?php } ?>

index.phtml

<?php } else { ?>
<?php } ?>
index.phtml

# Alias for Ext.ux.util.MessageBus
Alias /js/ext-ux-util-messagebus "/htdocs/your_project/vendor/ext-ux-util-messagebus/src"
<Directory "/htdocs/your_project/vendor/ext-ux-util-messagebus/src">
Order allow,deny
Allow from all
</Directory>
apache.conf

<?php } else { ?>
<?php } ?>
index.phtml

Alias /js/ext-ux-util-messagebus "/htdocs/your_project/vendor/ext-ux-util-messagebus/src"
<Directory "/htdocs/your_project/vendor/ext-ux-util-messagebus/src">
Order allow,deny
Allow from all
</Directory>
apache.conf


index.phtml

Development: Alias /js/ext-ux-util-messagebus
Virtual

Virtual

Build: ...
<target name="build_js">
<delete dir="./build/js/ext-ux-util-messagebus" />
<copy todir="./build/js/ext-ux-util-messagebus" includeemptydirs="true">
<fileset dir="./vendor/ext-ux-util-messagebus">
<exclude name="**/.svn" />
</fileset>
</copy>
</target>
... Build process

Virtual

Build: ...
<target name="build_js">
<delete dir="./build/js/ext-ux-util-messagebus" />
<copy todir="./build/js/ext-ux-util-messagebus" includeemptydirs="true">
<fileset dir="./vendor/ext-ux-util-messagebus">
<exclude name="**/.svn" />
</fileset>
</copy>
</target>
... Build process


index.phtml


Cons
● will need some webserver configuration to get things
working
● build-files depend on initial layout, changes mean
adjustment at several locations at once
● needs documentation for your dev team
● users need to know how to set up their dev
environment when they check out „including sources“

Pros
● No symlinks –> not f***ing up the repository
● Code structured after purpose
● No need to run builds after you've changed one line of
code (except for tests, of course)
● Clean approach towards build- and development-code
● Makes build-definitions easy due to strictly defined
layout

Advice:
● Use svn.ignore and template files! - it will help you and you're
coworkers to set up things on different machines

Context based data

What is a „context“?

Context based data

Application Server

Context based data

Application Server

send/receive

Desktop PC

Context based data

Application Server

send/receive send/receive

Desktop PC Mobile

Context based data

Application Server


Desktop PC Mobile

Context „default“

Context based data

Application Server


Desktop PC Mobile

Context „default“ Context „mobile“

Context based data

Why do we need it?

Context based data
● Different devices need different views
● Content delivery optimizations
● One domain serves all (www.senchadevcon.eu
vs. m.senchadevcon.eu)
● Specific data format (send/receive) might not be
available on devices used by our users

Context based data

What do we need?

Context based data

class Zend_Controller_Action_Helper_ContextSwitch
ContextSwitch.php

Context based data

class Zend_Controller_Action_Helper_ContextSwitch
ContextSwitch.php

● Action helper that will detect context based requests

● Capable of sending specially formatted responses based on
detected context and configuration

● Available as a default action helper provided by Zend Framework

●
For more informations on how to use action helper, see [3]

Context based data

How does it work?

Context based data - detection
We can define a context based on (virtually) all data
that's available during runtime!

For example:
http://myproject.com/user/reception/get.user/format/json

url

For example:

url

module

For example:

url

controller

For example:

url

action

For example:

url

parameter/value pair

For example:

url

$_GET['format'] == 'json'

For example:

url


● Application is now in „json“ context – i.e., return all responses
json formatted, since the client told us so!

For example:

url


● Application is now in „json“ context – i.e., return all responses
json formatted, since the client told us so!
● In fact, this is a default option coming with the ContextSwitch
action helper

Another example:
...
$userAgent = strtolower($_SERVER['HTTP_USER_AGENT']);

// request coming from ipad?
if (strpos($userAgent, 'ipad') !== false) {

$this->currentContext = 'ipad';

// request coming from android?
} else if (strpos($userAgent), 'android') !== false) {

$this->currentContext = 'android';

}
...
User Agent

● Context set by detection, not manually enforced by
parameters

Context based data

So what can it do for me?

Context based data
● Detect devices/users (webbrowser, mobile, bots)

Context based data
● One codebase for all devices: „Write once, run
anywhere“

Context based data
● One codebase for all devices:„Write once, run
anywhere“
● View variables will either be assigned to templates
(plain html mixed with PHP for example) or
transformed to json (xml etc.) – automatically – no
need to implement special logic as long as your client
can handle the response
● Requesting different formats is often just a thing of
switching a parameter at client site
● Makes even delivering views from the backend very easy!
● Test a context by switching a parameter
● Only views? No, different business logic depending on
the context, too!

Context based data - example
class User_ReceptionController extends Zend_Controller_Action() {

public function init()
{
// define the actions that should consider different contexts
$this->_helper->contextSwitch()
->addActionContext('get.user', 'json')
->initContext();
}

/**
* This method will return user data to the client as requested.
*/
public function getUserAction()
{
...
$this->view->userName = 'Peter Griffin';
$this->view->userEmail = 'peter@birdistheword.com';
}

}

ReceptionController.php


{
implement parent's init() method
->initContext();
} to add action contexts...

/**
*/
{
...
}

}



{
->initContext();
}

/**
...which happens here:
*/
{
...
}

}



{
->initContext();
}

/**
getUserAction() will now...
*/
{
...
}

}



{
->initContext();
}

/**
* This method will return user data response json-formatted if
… return the to the client as requested.
*/ the get-Parameter „format“ was set to „json“
{
...
}

}



{
->initContext();
}

/**
*/
{
...
} We have just added an action
context to this action
}



{
->initContext();
}

/**
*/ Call business logic...
{
...
}

}



{
->initContext();
}

/**
*/ And finally: Assign values to the
public function getUserAction() controller's view
{
...
}

}


...
{
...
}

}

Ext.Ajax.request({
url : „/user/reception/get.user/format/json“,
success : function(response) {
console.log(response.responseText);
}
});
client.js

...
{
...
}
Module
}

Ext.Ajax.request({
}
});
client.js

...
{
...
}
Controller
}

Ext.Ajax.request({
}
});
client.js

...
{
...
}
Action
}

Ext.Ajax.request({
}
});
client.js


Note
● This illustration explains
how a request gets
processed by Zend
Framework [6]
● We'll use it to show how
ContextSwitch changes
the ResponseObject
based on the
application's context

Request

Client invokes request

Request Router

Zend Framework routes to
User_ReceptionController::getUserAction()

Request Router pre Any plugins defined?
Dispatch Signal a preDispatch to them!

Request Router pre Any plugins defined?
Dispatch Signal a preDispatch to them!

public function preDispatch()
{
}
Zend_Controller_Action_Helper_Abstract

Request Router pre Dispatch the action –
Dispatch getUserAction() gets processed!

Dispatch

Request Router pre
Dispatch

Dispatch
Action
Controller

{
...
}

Request Router pre
Dispatch

Action
Dispatch
Controller

Any plugins defined?
post Signal a postDispatch to them!
Dispatch

Request Router pre
Dispatch

Action
Dispatch
Controller

Any plugins defined?
post Signal a postDispatch to them!
Dispatch

public function postDispatch()
{
$context = $this->getCurrentContext();
...
//$this->postJsonContext();
}
ContextSwitch.php

Request Router pre
Dispatch

Action
Dispatch
Controller

post
Dispatch
$response->setHeader('Content-Type', 'application/json');
ContextSwitch.php

actions
left?

Response
Object

Request Router pre
Dispatch

Action
Dispatch
Controller

post
Dispatch
$response->setHeader('Content-Type', 'application/json');
ContextSwitch.php

actions
left?
$response->setBody(Zend_Json::encode($view->getVars()));
ContextSwitch.php

Response
Object

Request Router pre
Dispatch

Action
Dispatch
Controller

post
Dispatch

actions
left?

send
response Response
Object

Request Router pre
Dispatch

Action
Dispatch
Controller

post
Dispatch

actions
left?
{'userName' : „Peter Griffin“, 'userEmail' : „peter@birdistheword.com“}

console

send
response Response
Object

Context based data

AWESOME!

This makes coding a real blast!

Skeptikal Hippo

It makes sense when working with Ext 1.*
and 2.*, but what about Ext.direct.*?

Ext.direct.*

What is Ext.direct.*?

Ext.direct.*

„Ext Direct is a platform and language agnostic
technology to remote server-side methods to the
client-side.“[4]

Ext.direct.*
● That new kid in class no one wants to play with

Ext.direct.*
● Bugs

Ext.direct.*
● Bugs
● Clumsy

Ext.direct.*
● Bugs
● Clumsy
● Implementation too complex

Ext.direct.*
● Bugs
● Clumsy
● The bad thing:
– Sencha started to focus remote functionality in their
library on Ext.direct.* with 3.*

Ext.direct.*
● Bugs
● Clumsy
● The bad thing:
– Sencha started to focus remote functionality in their
library on Ext.direct.* with 3.*
● The good thing:
– Sencha eliminated almost all implementation issues

Ext.direct.* - advantages
● Let's you call remote procedures directly from
client code
class User_ReceptionController extends Zend_Controller_Action {

{
...
}
} ReceptionController.php

client code

{
...
}

user.reception.getUser();
client.js

client code

{
...
}
module

client.js

client code

{
...
}
controller

client.js

client code

{
...
}
action

client.js

● Can stack remote procedure calls and send
them as one „batched request“
class Groupware_AccountController extends Zend_Controller_Action {

public function getEmailAccountsAction(){ ... }

public function getFeedAccountsAction(){ ... }
}
GroupwareController.php



}

groupware.account.getEmailAccounts();

client.js



}

groupware.account.getFeedAccounts();
client.js

Firebug



}

client.js

POST http://sourcedevcon/groupware/account/get.email.accounts
POST http://sourcedevcon/groupware/account/get.feed.accounts

Firebug



}

client.js


Firebug

POST http://sourcedevcon/groupware

Firebug



}

client.js


Firebug

extDirectData
[{"action":"account","method":"getEmailAccounts","data":null,"type":"rpc","tid":1},
{"action":"account","method":"getFeedAccounts","data":null,"type":"rpc","tid":2}]
Firebug

Ext.direct.*

Batched request – what gives?

Ext.direct.*
● Can reduce serverload (1 request with n calls to
specific actions instead of n calls)

Ext.direct.*
● Reduces possibility of losing connections (http
allows for n concurrent connections to one
domain at a time)

Ext.direct.*
● Reduces possibility of losing connections (http
allows for n concurrent connections to one
domain at a time)

This alone are tremendously important reasons
for you to go ahead and make friendship with
that new kid in class!

Ext.direct.* w/ Zend Framework

Unfortunately, not supported out of the box :(


… so let's find a solution.
Let's sum up our goals:


● Switch client code to Ext.direct.* without having to
change backend source code
● Add another tier of complexity and automatically
create backend methods/client code. Tests,
changing naming conventions etc. have to be
added by hand then.
● Keep our backend testable, reusable and make
sure it runs with any other client library/
implementation


What we need to do:


– Show requests sent by Ext.direct.* their way through
Zend Framework to their module/controller/action
– Teach Zend Framework how to distinguish between old
fashioned and merged requests
– Show Zend Framework how to disassemble 1 request
into n requests
– Give Zend Framework a sandbox where it can
work/play/you name it with a disamssembled request
– Collect sandboxed requests and merge them back into
one response


Change Ext.direct.RemotingProvider
URLs on the fly

Remember?
The Ext.direct.RemotingProvider exposes access to
server side methods on the client.
By mapping those remote methods to the client, there is
almost no need anymore to spray URLs around the
source like crazy.
It establishes a connection between the client and the
backend by providing a programmer friendly interface.

Ext.direct.Manager.addProvider({
id : 'eu.sourcedevcon.provider',
enableUrlEncode : 'extDirectData',
url : './groupware',
format : 'json',
type : 'zend',
actions : {
account : [{
name : 'getFeedAccounts'
}, {
name : 'getEmailAccounts'
}]
},
namespace : 'eu.sourcedevcon.provider'
}); client.js

url : './groupware', URL
format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

format : 'json',
type : 'zend',
actions : {
account : [{ „action“
}, {
}]
},
}); client.js

format : 'json',
type : 'zend',
actions : {
}, {
name : 'getEmailAccounts' method
}]
},
}); client.js

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

eu.sourcedevcon.provider.account.getEmailAccounts();
client.js

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
});
namespace client.js

client.js

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}] action
},
}); client.js

client.js

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
namespace : 'eu.sourcedevcon.provider' method
}); client.js

client.js

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

client.js


Firebug

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

client.js

extDirectData
{"action":"account","method":"getEmailAccounts","data":null,"type":"rpc","tid":1}
Firebug

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

client.js

extDirectData
Firebug

if (isset($_POST['extDirectData'])) {
...
}
/groupware Firebug

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

client.js

extDirectData
Firebug

if (isset($_POST['extDirectData'])) { http://sourcedevcon/groupware/account/get.email.accounts
...
}
/groupware Firebug

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

URL = module
client.js

extDirectData
Firebug

if (isset($_POST['extDirectData'])) { Http://sourcedevcon/groupware/account/get.email.accounts
...
}
/groupware Firebug

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

URL = module
client.js
action = controller
extDirectData
Firebug

...
}
/groupware Firebug

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

URL = module
client.js
action = controller
extDirectData
method = action
Firebug

...
}
/groupware Firebug

format : 'json',
type : 'zend',
actions : {
}, {
name : 'getEmailAccounts' method
}]
},
}); client.js

URL = module
client.js
action = controller
extDirectData
method = action
Firebug

...
}
/groupware Firebug

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

Ext.define('eu.sourcedevcon.direct.ZendProvider', {

alias : 'direct.zendprovider',

extend : 'Ext.direct.RemotingProvider'

});
ZendProvider.js

URL = module action = controller method = action

client.js


Ext.Ajax.on('beforerequest', function(conn, options) {

var trans = options.transaction;

if (trans && trans.provider && trans.provider.type == 'zend') {
var controller = options.transaction.action;
controller = controller.replace(/([a-z])([A-Z])/g, "$1.$2").toLowerCase();
var action = options.transaction.method;
action = action.replace(/([a-z])([A-Z])/g, "$1.$2").toLowerCase();

var module = options.url;
var url = module + (module.lastIndexOf('/') == module.length-1 ? '' : '/') +
controller + '/' + action;

if (options.transaction.provider.format) {
url += '/format/' + options.transaction.provider.format;
}

options.url = url;
options.disableCaching = true;

}
}); client.js






if (options.transaction.provider.format) { ContextSwitch
}

options.url = url;

}
}); client.js

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

client.js


format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

client.js


POST http://sourcedevcon/groupware/account/get.email.accounts/format/json
extDirectData
Firebug

extDirectData
Firebug

Note:
● Teach your actions the „extDirectData“-POST parameter

extDirectData
Firebug

Note:
● Teach your actions the „extDirectData“-POST parameter
● Your responses must return the „tid“ as received by the
request


Will do! Let me send a batched request now!

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

eu.sourcedevcon.provider.account.getFeedAccounts();
client.js

format : 'json',
type : 'zend',
actions : {
account : [{
}, {
}]
},
}); client.js

eu.sourcedevcon.provider.account.getFeedAccounts();
client.js

extDirectData

Firebug


...?

queueTransaction: function(transaction){
var me = this,
enableBuffer = me.enableBuffer;

if (transaction.form) {
me.sendFormRequest(transaction);
return;
}

me.callBuffer.push(transaction);
if (enableBuffer) {
if (!me.callTask) {
me.callTask = Ext.create('Ext.util.DelayedTask', me.combineAndSend, me);
}
me.callTask.delay(Ext.isNumber(enableBuffer) ? enableBuffer : 10);
} else {
me.combineAndSend();
}
}
RemotingProvider.js

queueTransaction: function(transaction){ add transaction to callBuffer Array
var me = this,
enableBuffer = me.enableBuffer;

return;
}

if (enableBuffer) {
if (!me.callTask) {
}
} else {
}
}
RemotingProvider.js

var me = this,
enableBuffer = me.enableBuffer; if batching is enabled, create a task

return;
}

if (enableBuffer) {
if (!me.callTask) {
}
} else {
}
}
RemotingProvider.js

var me = this,
wait for 10ms for another
transaction to be added
return;
}

if (enableBuffer) {
if (!me.callTask) {
}
} else {
}
}
RemotingProvider.js

var me = this,
wait for 10ms for another
transaction to be added
no more transactions coming in? Call
return;
combineAndSend
}

if (enableBuffer) {
if (!me.callTask) {
}
} else {
}
}
RemotingProvider.js

eu.sourcedevcon.provider.account.getFeedAccounts(); client.js





}

options.url = url;

}
}); client.js


false



}

options.url = url;

}
}); client.js


false

...

client.js

extDirectData

Firebug


...and now for something
completely different.

Introducing

Sourcedevcon_Controller_Plugin_ExtRequest[5]

What is this Plugin?
● „Plugin“ for Zend Framework's Front Controller
● Actually not a real plugin, but rather a mediator for
preDispatch/postDispatch Events
● Capable of detecting batched requests
● Capable of disassembling a batched request into
individual requests
● Capable of creating a sandbox for each request,
and processing it


dispatchLoopStartup


dispatchLoopStartup

dispatchLoopShutdown

pre
Dispatch

Action
Dispatch
Controller
dispatchLoopStartup

post
dispatchLoopShutdown
Dispatch

Response
Object

$extDirect = new Sourcedevcon_Controller_Plugin_ExtRequest(array(
'extParameter' => 'extDirectData',
'additionalHeaders' => array('Content-Type' => 'application/json'),
'additionalParams' => array('format' => 'json'),
'action' => 'multi.request',
'controller' => 'ext',
'module' => 'default'
));

$extDirect->registerPlugins();
index.php

$extDirect = new Sourcedevcon_Controller_Plugin_ExtRequest(array(
'extParameter' => 'extDirectData', The POST parameter that
holds a batched request
'additionalHeaders' => array('Content-Type' => 'application/json'),
'additionalParams' => array('format' => 'json'),
'action' => 'multi.request',
'controller' => 'ext',
'module' => 'default'
));

$extDirect->registerPlugins();
index.php

Zend Framework MVC driven ExtJS

Zend Framework MVC driven ExtJS

Recommended

Recommended

More Related Content

Similar to Zend Framework MVC driven ExtJS

Similar to Zend Framework MVC driven ExtJS (20)

More from Thorsten Suckow-Homberg

More from Thorsten Suckow-Homberg (6)

Recently uploaded

Recently uploaded (20)

Zend Framework MVC driven ExtJS