typo3 flow package best practices

Package best practices

April 20, 2013

Saturday 20 April 13 / CW:

Flow package best practices

Pankaj Lele - [email protected]

April 20, 2013

About me

• Pankaj Lele

• Live in Goa, India

• Lelesys Founder Director and CTO (10+ years)

• @pankajlele

2


mailto:[email protected]



Flow package best practicesApril 20, 2013

My Flow experience

3

• 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 ...

4

• Efficiency

• Assuring quality

• Avoiding common errors

• Flexibility






5

Best practices

Architecture Coding






6

A deep thinking architect ...






#1

• Good to define full class design with UML

7

Architecture






#1

8

Architecture

ArgoUML

(all platforms)






#2

• Avoid unnecessary bi-directional associations in your domain model

9

Architecture






#3

• Always good to define interfaces

• defaults - Objects.yaml

• ReflectionService

10

Architecture






#3

11

Architecture

For example, PaymentHandlerInterface






#4

• Avoid defining static functions

• PhpUnit limitations for mocks

12

Architecture






#5

• Good to define domain services

13

Architecture






#5

14

Architecture






#6

• Good to use doctrine inheritance mapping if possible

15

Architecture






#6

16

Architecture

BAD

class Media { /** * The title of media * @var string */ protected $title; /** * The type one of 'audio' or 'video' * @var string */ protected $type; }






#6

17

Architecture

GOOD

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

class Audio extends AbstractMedia { }

class Video extends AbstractMedia { }






#7

• Good to define class constants

• no need to remember values

18

Architecture






#7

19

Architecture

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);






20

Best practices

Architecture Coding






Post-kickstart

21






#8

• Good to define methods addX(), removeX() and getXs() for collections

• example: TYPO3\Party\Domain\Model\AbstractParty

22

Coding:Post-kickstart






#9

• Always good to initialize collections in entity class constructor

• recommended by Doctrine

23







#10

• Always annotate properties with validators right away after kickstart

24







#11

• Always remove unused controller actions created by kick-starter

25







Debugging

26






#12

• Always use \TYPO3\Flow\var_dump() for debugging variables

• no more memory full errors

• object information

27

Coding:Debugging






#12

28

Coding:Debugging






#13

• Best to use package debug/toolbar

• queries executed

• functions called

29

Coding:Debugging






Composer

30






#14

• Always maintain composer.json right away

• document what you used

• ext-zip or ext-imagick

31

Coding:Composer






Configuration

32






#15

• Good to set defaultLocale setting

• application’s default language

• helps formatting numbers and currencies automatically

33

Coding:Configuration






#16

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

34







#17

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

35







MVC

36






#18

• Always map all GET/POST variables as action arguments

37

Coding:MVC






#18

38

Coding:MVC

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

BAD






#18

39

Coding:MVC

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

Good






#19

• Good to have an AbstractController

• assign logged in user to the view

• inject common dependencies

40

Coding:MVC






#20

• Avoid exit() call inside controller action

• StopActionException() is what you want

41

Coding:MVC






#21

• Good to use StandAloneView

• render e-mail templates

42

Coding:MVC






Session

43






#22

• Avoid using direct session API

• encapsulate

• session scoped class

• example: ShoppingCart

44

Coding:Session






Dependency Injection

45






#23

• Always inject interfaces

• proper factory object is used

• change implementation via Objects.yaml

46

Coding:Dependency

Injection






#24

• inject TYPO3\Flow\Session\SessionInterface

• current active session

• inject TYPO3\Flow\Session\Session

• completely new session

47

Coding:Dependency

InjectionIf you really want to ...






Persistence

48






#25

• Frequently call ./flow doctrine:validate

• after kickstart + modifications

• after each change in domain model

49

Coding:Persistence






#26

• Always use doctrine migrations for database update

• doctrine:update/create not good for serious projects

50

Coding:Persistence






#27

• Always test “down” doctrine migrations

• good for change rollback

51

Coding:Persistence






#28

• Always separate out doctrine migrations of respective packages

52

Coding:Persistence






#29

• Good to use doctrine migrations also for migrating data

• $this->connection

53

Coding:Persistence






#30

• Good do not mention any collation or use utf8_unicode_ci in doctrine migrations

• my.cnf "collation-server"

54

Coding:Persistence






#31

• Do not delete/modify doctrine migration files once committed

• always generate new migration on each domain model change

55

Coding:Persistence






#32

• Always pull upstream code changes

• doctrine:migrate

• doctrine:migrationgenerate

56

Coding:Persistence






#33

• Good to use DQL at some places

• aggregations

• joins

• avoid nested foreach loops

• warning: QOM based widgets

57

Coding:Persistence






Resources

58






#34

• If needed, good to write files in /Data

• Persistent

• Temporary

• Utility\Environment

59

Coding:Resources






Development Environment

60






#35

• Good to ignore directories in your favorite IDE

• Data/Temporary, Logs, Persistent

• speeds up the IDE

• proxy classes ignored

61

Coding:Development Environment






#36

• Good to freeze packages not changed so often

• freeze framework packages

• ./flow package:freeze

62

Coding:Development Environment






Error Proofing

63






#37

• Always type-hint method arguments

• strict expectations

64

Coding:Error proofing






Error Handling

65






#38

• Always throw exceptions from domain services

• catch in controllers

• better error reporting to the user

66

Coding:Error handling






Utilities

67






#39

• Always look for available TYPO3\Flow\Utility

• get things done the way framework likes

• environment, files, algorithms, array

68

Coding:Utilities






Bootstrap

69






#40

• Good to rely on FLOW_* constants

• paths

70

Coding:Bootstrap






Troubleshooting

71






#41

• Always find exact database error

• SHOW INNODB STATUS

72

Coding:Troubleshooting






Testing

73






#42

• Unit tests which test business logic

• usually test domain services

• persistence mocked

74

Coding:Testing






#43

• Functional tests which test user stories

• test controllers

• virtual browser

• in-memory persistence

75

Coding:Testing






Performance

76






#44

• Good to analyze performance

• sandstorm/plumber

• xhprof just profiler

• inclusive/exclusive timing

• no code changes

77

Coding:Performance






#45

• Always good to cache stuff

• caching framework

• front-ends

• backends

78

Coding:Performance






Thank you!

79






Questions?

80




typo3 flow package best practices

Technology

kickstart

pankaj lele

pankaj lele

doctrine migrations

doctrine migrations

pankajlelesys

2013 flow

2013 flow