Главная| Трекер ▼| Поиск| Правила| FAQ| |
Автор | Сообщение |
---|---|
valeri[µ]
Модератор ![]() Сообщения: 7870 ![]() |
A Year With Symfony
![]() Год: 2014 Автор: Matthias Noback Издательство: https://leanpub.com/a-year-with-symfony/ ISBN: 978-9082120110 Язык: Английский Формат: PDF Качество: Изначально компьютерное (eBook) Количество страниц: 205 Описание: About the Book I've written A Year With Symfony for you, a developer who will work with Symfony2 for more than a month (and probably more than a year). You may have started reading your way through the official documentation ("The Book"), the cookbook, some blogs, or an online tutorial. You know now how to create a Symfony2 application, with routing, controllers, entities or documents, Twig templates and maybe some unit tests. But after these basic steps, some concerns will raise about... - The reusability of your code - How should you structure your code to make it reusable in a future project? Or even in the same project, but with a different view or in a console command? - The quality of the internal API you have knowingly or unknowingly created - What can you do to ensure that your team members will understand your code, and will use it in the way it was meant to be used? How can you make your code flexible enough to be used in situations resembling the one you wrote it for? - The level of security of your application - Symfony2 and Doctrine seem to automatically make you invulnerable for well-known attacks on your web application, like XSS, CSRF and SQL injection attacks. But can you completely rely on the framework? And what steps should you take to fix some of the remaining issues? - The inner workings of Symfony2 - When you take one step further from creating just controllers and views, you will soon need to know more about the HttpKernel which is the heart of a Symfony2 application. How does it know what controller should be used, and which template? And how can you override any decision that's made while handling a request? To get a better idea about the book, take a look at the table of contents below), or download a sample of the book above. Foreword Introduction Thank you Who should read this book Conventions Overview of the contents I The journey from request to response 1 The HttpKernelInterface 1.1 Booting the kernel Bundles as container extensions Creating the service container 1.2 From the Kernel to the HttpKernel 2 Events leading to a response 2.1 Early response Some notable kernel.request event listeners 2.2 Resolving the controller 2.3 Allow replacement of the controller Some notable kernel.controller listeners 2.4 Collect arguments for executing the controller 2.5 Execute the controller 2.6 Enter the view layer A notable kernel.view listener 2.7 Filter the response Notable kernel.response listeners 3 Exception handling 3.1 Notable kernel.exception listeners 4 Sub-requests 4.1 When are sub-requests used? II Patterns of dependency injection 5 What is a bundle? 6 Service patterns 6.1 Required dependencies Required constructor arguments Abstract definitions for extra arguments Required setter calls Method calls in abstract definitions 6.2 Optional dependencies Optional constructor arguments Optional setter calls 6.3 A collection of services Multiple method calls The best of both worlds Service tags Single method call Replacing a single argument Service ids instead of references 6.4 Delegated creation Not so useful Sometimes useful 6.5 Manually creating services Definition Arguments Tags Aliases 6.6 The Configuration class 6.7 Dynamically add tags 6.8 Strategy pattern for loading exclusive services 6.9 Loading and configuring additional services A cleaner configuration class 6.10 Configure which services to use 6.11 Completely dynamic service definitions 7 Parameter patterns 7.1 Parameters.yml 7.2 Parameter resolving Parameters for class names Manually resolving parameters 7.3 Define parameters in a container extension 7.4 Override parameters with a compiler pass III Project structure 8 Organizing application layers 8.1 Slim controllers 8.2 Form handlers 8.3 Domain managers 8.4 Events Persistence events 9 State and context 9.1 The security context 9.2 The request Avoiding a dependency on the current request Use an event listener Providing the request object at runtime Using specific values only IV Configuration conventions 10 Application configuration setup 10.1 Use local configuration files Keep parameters.yml Add a default_parameters.yml 11 Configuration conventions 11.1 Routing Choosing Route Names 11.2 Services 11.3 Mapping metadata V Security 12 Introduction 12.1 Symfony and security 12.2 Goals: prevention and confinement Minimize impact Reflection Before diving in… 13 Authentication and sessions 13.1 Invalidating sessions Session hijacking Long-running sessions 14 Controller design 14.1 Secure actions 14.2 Putting controllers behind the firewall 15 Input validation 15.1 Safe forms HTML5 validation Validation constraints Forms without an entity 15.2 Validate values from Request Request attributes Route parameters Query or request parameters Use the ParamFetcher 15.3 Sanitizing HTML Automatic sanitizing 16 Output escaping 16.1 Twig Know your escaping context Escaping function output Escaping function arguments Be wary of the raw filter 17 Being secretive 17.1 Mask authentication errors 17.2 Prevent exceptions from showing up 17.3 Customize error pages 17.4 Be vague about user data VI Using annotations 18 Introduction Annotations: Domain-specific languages 19 An annotation is a simple value object 19.1 Adding attributes to your annotation Passing the attributes via the constructor Populating public properties with the provided attributes Validation using @Attributes Validation using @var and @Required 19.2 Limiting the use of an annotation 20 Valid use cases for annotations 20.1 Loading configuration Annotations and coupling 20.2 Controlling application flow 21 Using annotations in your Symfony application 21.1 Responding to Request attributes: the @Referrer annotation 21.2 Prevent controller execution: the @RequiresCredits annotation 21.3 Modify the response: the @DownloadAs annotation 22 Designing for reusability 23 Conclusion VII Being a Symfony developer 24 Reusable code has low coupling 24.1 Separate company and product code 24.2 Separate library and bundle code 24.3 Reduce coupling to the framework Event listeners over event subscribers Constructor arguments over fetching container parameters Constructor arguments over fetching container services The performance issue Framework-agnostic controllers Thin commands The environment 25 Reusable code should be mobile 25.1 Dependency management and version control Package repositories 25.2 Hard-coded storage layer Auto-mapped entities Storage-agnostic models Object managers 25.3 Hard-coded filesystem references Using the filesystem 26 Reusable code should be open for extension 26.1 Configurable behavior 26.2 Everything should be replaceable Use lots of interfaces Use the bundle configuration to replace services 26.3 Add extension points Service tags Events 27 Reusable code should be easy to use 27.1 Add documentation 27.2 Throw helpful exceptions Use specific exception classes Set detailed and friendly messages 28 Reusable code should be reliable 28.1 Add enough tests Test your bundle extension and configuration Conclusion Помоги нашему сайту на расходы за сервер и качай торренты НЕОГРАНИЧЕННО!Пожертвовать 100 ₽ ![]() Или 2204 1201 2214 8816, с комментарием "Помощь трекеру" Связь с администрацией |
Страница 1 из 1 |
![]() |
|