TYPO3 Flow package best practices

Package best practices

April 20, 2013

Saturday 20 April 13 / CW:

April 20, 2013 Flow package best practices

About me

• Pankaj Lele

• Live in Goa, India

• Lelesys Founder
Director and CTO (10+
years)

• @pankajlele

Pankaj Lele - pankaj@lelesys.com 2


My Flow experience

• Large scale enterprise project
• Full agile development with 7 teams, 3
countries, 20+ developers
• Start with FLOW3 1.0 Nov. 2011
• First public version March 2012



45 best practices for ...

• Efﬁciency
• Assuring quality
• Avoiding common errors
• Flexibility



Best practices

Architecture Coding



A deep thinking architect ...



Architecture
#1

• Good to deﬁne full class design with
UML



Architecture
#1

ArgoUML

(all platforms)



Architecture
#2

• Avoid unnecessary bi-directional
associations in your domain model



Architecture
#3

• Always good to deﬁne interfaces
• defaults - Objects.yaml
• ReﬂectionService



Architecture
#3
For example, PaymentHandlerInterface



Architecture
#4

• Avoid deﬁning static functions
• PhpUnit limitations for mocks



Architecture
#5

• Good to deﬁne domain services



Architecture
#5



Architecture
#6

• Good to use doctrine inheritance
mapping if possible



Architecture
#6
BAD
class Media {

/**
* The title of media
* @var string
*/
protected $title;

/**
* The type one of 'audio' or 'video'
* @var string
*/
protected $type;
}



Architecture
#6
GOOD

class Audio extends
class AbstractMedia {
AbstractMedia {
/**
}
* The title of media
* @var string
class Video extends
*/
AbstractMedia {
protected $title;
}
}



Architecture
#7

• Good to deﬁne class constants
• no need to remember values



Architecture
#7
GOOD
class ElectronicAddress {

const TYPE_AIM = 'Aim';
const TYPE_EMAIL = 'Email';
const TYPE_ICQ = 'Icq';
const TYPE_JABBER = 'Jabber';
}

$electronicAddress = new ElectronicAddress();
$electronicAddress->setType(ElectronicAddress::TYPE_EMAIL);



Best practices

Architecture Coding



Post-kickstart



Coding:
Post-kickstart #8

• Good to deﬁne methods addX(),
removeX() and getXs() for collections
• example: TYPO3PartyDomainModel
AbstractParty



Coding:
Post-kickstart #9

• Always good to initialize collections
in entity class constructor
• recommended by Doctrine



Coding:
Post-kickstart #10

• Always annotate properties with
validators right away after kickstart



Coding:
Post-kickstart #11

• Always remove unused controller
actions created by kick-starter



Debugging



Coding:
Debugging #12

• Always use TYPO3Flow
var_dump() for debugging variables
• no more memory full errors
• object information



Coding:
Debugging #12



Coding:
Debugging #13

• Best to use package debug/toolbar
• queries executed
• functions called



Composer



Coding:
Composer #14

• Always maintain composer.json right
away
• document what you used
• ext-zip or ext-imagick



Conﬁguration



Coding:
Conﬁguration #15

• Good to set defaultLocale setting
• application’s default language
• helps formatting numbers and
currencies automatically



Coding:
Configuration #16

• Always run ./flow
configuration:validate to check
whether package *.yaml files are valid



Coding:
Configuration #17

• Always crosscheck package
configuration using ./flow
configuration:show



MVC



Coding:
MVC #18

• Always map all GET/POST variables as
action arguments



Coding:
MVC #18
BAD

/**
* Create action
*
* @return void
*/
public function createAction() {
$newVideo = $this->request->getHttpRequest()->getArgument('newVideo');
// ....
}



Coding:
MVC #18
Good

/**
* Create action
*
* @param Video $newVideo The video
* @return void
*/
public function createAction(Video $newVideo) {
// ....
}



Coding:
MVC #19

• Good to have an AbstractController
• assign logged in user to the view
• inject common dependencies



Coding:
MVC #20

• Avoid exit() call inside controller action
• StopActionException() is what you
want



Coding:
MVC #21

• Good to use StandAloneView
• render e-mail templates



Session



Coding:
Session #22

• Avoid using direct session API
• encapsulate
• session scoped class
• example: ShoppingCart



Dependency Injection



Coding:
Dependency #23
Injection

• Always inject interfaces
• proper factory object is used
• change implementation via Objects.yaml



Coding:
Dependency #24
Injection
If you really want to ...

• inject TYPO3FlowSessionSessionInterface
• current active session
• inject TYPO3FlowSessionSession
• completely new session



Persistence



Coding:
Persistence
#25

• Frequently call ./ﬂow
doctrine:validate

• after kickstart + modiﬁcations
• after each change in domain model



Coding:
Persistence
#26

• Always use doctrine migrations for
database update
• doctrine:update/create not good
for serious projects



Coding:
Persistence
#27

• Always test “down” doctrine
migrations

• good for change rollback



Coding:
Persistence
#28

• Always separate out doctrine
migrations of respective packages



Coding:
Persistence
#29

• Good to use doctrine migrations also for
migrating data

• $this->connection



Coding:
Persistence
#30

• Good do not mention any collation or
use utf8_unicode_ci in doctrine
migrations
• my.cnf "collation-server"



Coding:
Persistence
#31

• Do not delete/modify doctrine
migration ﬁles once committed
• always generate new migration on
each domain model change



Coding:
Persistence
#32

• Always pull upstream code changes
• doctrine:migrate
• doctrine:migrationgenerate



Coding:
Persistence
#33

• Good to use DQL at some places
• aggregations
• joins
• avoid nested foreach loops
• warning: QOM based widgets


Resources



Coding:
Resources
#34

• If needed, good to write ﬁles in /Data
• Persistent
• Temporary
• UtilityEnvironment



Development Environment



Coding:
Development #35
Environment

• Good to ignore directories in your
favorite IDE

• Data/Temporary, Logs, Persistent
• speeds up the IDE
• proxy classes ignored



Coding:
Development #36
Environment

• Good to freeze packages not changed
so often
• freeze framework packages
• ./ﬂow package:freeze



Error Prooﬁng



Coding:
Error prooﬁng
#37

• Always type-hint method arguments
• strict expectations



Error Handling



Coding:
Error handling
#38

• Always throw exceptions from domain
services
• catch in controllers
• better error reporting to the user



Utilities



Coding:
Utilities
#39

• Always look for available TYPO3Flow
Utility
• get things done the way framework likes
• environment, ﬁles, algorithms, array



Bootstrap



Coding:
Bootstrap
#40

• Good to rely on FLOW_* constants
• paths



Troubleshooting



Coding:
Troubleshooting
#41

• Always ﬁnd exact database error
• SHOW INNODB STATUS



Testing



Coding:
Testing
#42

• Unit tests which test business logic
• usually test domain services
• persistence mocked



Coding:
Testing
#43

• Functional tests which test user
stories

• test controllers
• virtual browser
• in-memory persistence



Performance



Coding:
Performance
#44

• Good to analyze performance
• sandstorm/plumber
• xhprof just proﬁler
• inclusive/exclusive timing
• no code changes


Coding:
Performance
#45

• Always good to cache stuff
• caching framework
• front-ends
• backends



Thank you!



Questions?


TYPO3 Flow package best practices

Recommandé

Recommandé

Contenu connexe

Dernier

Dernier (20)

En vedette

En vedette (20)

TYPO3 Flow package best practices