PHP Web Development with Laminas E-Book

Flávio Gomes da Silva Lisboa

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 400

Veröffentlichungsjahr: 2022

Beschreibung

Considered the next generation of the Zend framework, Laminas is a high-performance PHP framework for creating powerful web applications with an evolutive architecture.
This book takes a hands-on approach to equip you with the knowledge of the Laminas framework necessary to start building web applications based on the reuse of loosely coupled components. You'll learn how to create the basic structure of a PHP web application divided into layers, understand Laminas’ MVC components, and be able to take advantage of the Eclipse platform as a method for developing with Laminas. Step by step, you'll build an e-commerce application based on the technical requirements of a fictional business, and get to grips with implementing those requirements using Laminas components.
By the end of this web development book, you’ll be able to build a completely secured MVC application in PHP language using Laminas.

Leseprobe

PHP Web Development with Laminas

Build a fully secured and functional e-commerce application with PHP using the Laminas framework

Flávio Gomes da Silva Lisboa

BIRMINGHAM—MUMBAI

PHP Web Development with Laminas

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Kushal Dave

Senior Editor: Mark D’Souza

Senior Content Development Editor: Rakhi Patel

Technical Editor: Simran Udasi

Copy Editor: Safis Editing

Project Coordinator: Sonam Pandey

Proofreader: Safis Editing

Indexer: Sejal Dsilva

Production Designer: Nilesh Mohite

Marketing Coordinators: Anamika Singh and Marylou De Mello

First published: November 2022

Production reference: 1201022

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80324-536-2

www.packt.com

To my wife, Maria, a warrior, the love of my life, who beat cancer. To my daughter, Koriander, a superheroine, who has empathy as one of her superpowers. To the memory of my mother, Cleonisse, who taught me how to read and let me travel the world in books.

– Flávio Lisboa

Foreword

PHP Web Development with Laminas by Flávio Gomes da Silva Lisboa is a very good book if you are interested in web development with PHP. The author shows how to implement, using a step-by-step approach, a complete e-commerce application with the Laminas open source project (formerly Zend Framework). I really liked the approach of the author, introducing not only the usage of the framework but also many best practices such as test-driven development, behavior-driven development, principles of Agile development, and more. This is definitely a book to have if you want to build professional web applications in PHP.

Enrico Zimuel, principal software engineer at Elastic Core Committee, member of the PHP Framework Interop Group, formerly Zend Framework core developer

Contributors

About the author

Flávio Gomes da Silva Lisboa is a development analyst in SERPRO involved in several projects for the Brazilian government, an instructor of development software courses, a teacher of development software disciplines, and a member of the Brazilian PHP community. He also was a programmer of desktop applications for restaurants and industrial kitchens and a system analyst on the international board of the Bank of Brazil. Sometimes, he writes sci-fi romances such as The One: The Solitude and the Harmony and Pandino, the Emperor. You can read more about him and his adventures at https://fgsl.eti.br.

I want to thank the people who have been close to me and supported me, especially my wife Maria and my daughter Koriander. They are the reason for which I want to progress. This text is readable thanks to the uncanny work of Divya Selvaraj and Rakhi Patel. I also need to thank Er Galvão and Matt Fletcher for their accurate technical reviewing. I can’t forget Eduardo Bona and Anderson Burnes, who were course coordinators when I taught Zend Framework, now Laminas, to several classes of IT college students. It is necessary to also thank Marcos Melo, Walter Zapalowski, Guilherme Funchal, and Antonio Tiboni, fellows in SERPRO, who helped me to work on an international project that used Zend Framework. Finally, I need to mention the years of partnership with Anderson de Paula in training PHP developers. Of course, this book wouldn’t be possible without the wonderful support of the Packt Publishing team, which gave me an incredible experience of writing. Thank you very much to Kushal Dave, Mark D’Souza, Sonam Pandey, and every member of Packt Publishing who was a part of the building of this book.

About the reviewer

Matt Fletcher is an experienced software engineer who has designed and developed PHP web applications for over 20 years. He is currently the development manager for SilverDoor Apartments, the leading booking agent for serviced apartments worldwide. He leads an international team of developers who use the Laminas framework and API Tools to deliver a range of enterprise tools. His work includes reviewing pull requests, planning system architectures, and delivering high-quality projects. 

Table of Contents

Preface

Part 1: Technical Background

1

Introducing Laminas for PHP Applications

Why do we need web frameworks?

Continuous integration and continuous delivery

The usefulness of a framework

From Zend Framework to Laminas

My introduction to Zend Framework

Zend Framework – the reference architecture for PHP applications

The differences between Zend Framework and Laminas

The technical and social infrastructure of the Laminas community

Summary

2

Setting Up the Environment for Our E-Commerce Application

Technical requirements

Installing Laminas

Installing Laminas through an isolated component of Laminas

Installing Laminas through an MVC skeleton application

Configuring the IDE – Eclipse for PHP developers

Integrating Laminas and Eclipse

Managing MySQL

Summary

3

Using Laminas as a Library with Test-Driven Development

Technical requirements

Understanding the requirements for developing our software

Use case – managing school classes

Implementing a structure for the use case

Creating our first automated test

Developing our use case with TDD

Creating our SchoolClassTest test class

Creating a test method in the SchoolClass class

Creating the SchoolClass class

Configuring autoloading of classes

Configuring the autoloading of test classes

Creating the config.php file and rerunning the SchoolClassTest test case

Creating a new testInserting test method

Creating an edition form edit.php

Creating a SchoolClassTest->testUpdating test method

Altering edit.php

Altering save.php

Creating the delete.php file

Generating code coverage reports

Summary

4

From Object-Relational Mapping to MVC Containers

Technical requirements

Using ORM

Use case – managing students

Implementing the use case

Running the SchoolClassTest->testListing test

Adjusting CRUD files

Using Laminas as a container

Creating the school3 project

Creating the School module

Ensuring the module has the right namespace

Implementing the test methods

Running the tests

Summary

Part 2: Creating an E-Commerce Application

5

Creating the Virtual Store Project

Technical requirements

Understanding the project requirements for the sample web application

Identifying use cases and actors

Understanding the class diagram for Whatstore

Creating the project instance

Understanding the structure of a Laminas project

Preparing the modules for our project

Summary

6

Models and Object-Relational Mappers with Behavior-Driven Development

Technical requirements

BDD with Behat

Creating our first scenario

Mapping a user story to an automated test

Creating models from user stories

Creating mappers from user stories

Adding a product to the products table

Checking whether the product was inserted

Creating a generic model and a generic mapper

Creating other models with Behat

Summary

7

Request Control and Data View

Technical requirements

Understanding the relationship between HTTP and PHP

The request life cycle in the Laminas MVC

Implementing CRUD with a controller and view pages

Testing our current test cases

Testing product insertion

Testing product recovery

Testing product updates

Testing product deletion

Creating the ProductAPIController class

Implementing the ProductController class

Implementing the pages for ProductController

Implementing the interaction between the web interface and API

Testing the interaction between the web interface and API

Summary

8

Creating Forms and Implementing Filters and Validators

Technical requirements

Generating a form for discounts with laminas-form

Creating CRUD implementation using the laminas-form component

Creating a class to define an HTML form

Filtering input data

Validating input data

Summary

9

Event-Driven Authentication

Technical requirements

Creating login and logout actions for the Inventory module

Creating tests for login and logout actions

Creating login and logout actions

Implementing the user authentication for the Inventory module

Creating the employee’s registration

Testing the login page

Verifying user identity based on events

Delegating the authentication listener to a module

Summary

10

Event-Driven Authorization

Technical requirements

Creating roles registration

Creating resources registration

Filling the resources table

Associating resources with roles

Associating roles with users

Implementing access control

Verifying users’ permissions

Modifying the test bootstrap

Creating an identity manager

Summary

Further reading

Part 3: Review and Refactoring

11

Implementing a Product Basket

Technical requirements

Managing the product inventory

Refactoring the customer home page

Controlling the product basket

Controlling the customers

Order closing

Decoupling the generic behavior of authentication

Summary

12

Reviewing and Improving Our App

Technical requirements

Principles of agile development

Eliminating duplicated code

Removing unnecessary configuration

Creating a product search box

Generating API documentation

Isolating identity management for each module

Modifying the class for identity management

Refactoring listener and controller classes

Summary

13

Tips and Tricks

Technical requirements

Creating mapped models

Customizing filters and validators

Creating a customized filter

Creating a customized validator

Understanding the Laminas view layer

Producing JSON responses with laminas-view

Uploading files with laminas-form

Changing the application layout

Mastering the controller layer

Detecting AJAX requests

Exchanging messages between the controller and view layers

Finishing controller actions

Summary

14

Last Considerations

Other Laminas components

Cache

CLI

Crypt

CSRF

DOM

Escaper

Feed

Hydrator

JSON-RPC server

LDAP

Log

Microservice-oriented development

Building APIs

Community resources

Summary

Index

Other Books You May Enjoy

Part 1: Technical Background

In this part of the book, you will obtain the necessary knowledge to prepare a free and open source development environment for object-oriented PHP web applications and an understanding of the basic concepts required to work with Laminas.

This section comprises the following chapters:

Chapter 1, Introducing Laminas for PHP ApplicationsChapter 2, Setting Up the Environment for Our E-Commerce ApplicationChapter 3, Using Laminas as a Library with Test-Driven DevelopmentChapter 4, From Object-Relational Mapping to MVC Containers

1

Introducing Laminas for PHP Applications

In April 2019, the Linux Foundation announced that it was launching a new project: Laminas. This was actually the new name for a project that had existed since 2006, Zend Framework. From that moment on, the PHP framework, which already had 400 million installs, would have a vendor-neutral home. But Zend Technologies has not abandoned the product that bears its name for several years. Zend continues to provide corporate support, which includes mission-critical support, enterprise adapter extensions, long-term support, and on-demand guidance from PHP experts.

This chapter presents the evolution of the architecture of Zend Framework until its change to Laminas and discusses the lessons learned. In this chapter, you will gain an understanding of why the framework team took some decisions instead of others during its evolution. These subjects are the motivation for a developer to use a framework, and Laminas is presented as one option for PHP developers.

In this chapter, we’ll be covering the following topics:

Why do we need web frameworks?From Zend Framework to LaminasThe technical and social infrastructure of the Laminas community

Why do we need web frameworks?

Some people may ask, Why do I need a framework? Such people may also ask, Why do I need to use classes? After all, PHP is simple and it no needs classes. With a few lines of code, you can produce a page with processed data from a database. Rasmus Lerdorf, the PHP creator, always claimed in his talks that PHP is fast and it requires neither classes nor frameworks to work. In 2014, Mariano Iglesias gave a lecture at PHP Conference Brazil, in which he defended a future without frameworks. Well, both Rasmus and Mariano are right, depending on the software complexity we are talking about. We cannot compare a personal page with just a few statistics to an enterprise system. When we talk about object-oriented programming (OOP) and frameworks, we are mainly talking about complexity control.

Martin Fowler states that one of the meanings that most people agree on for the term architecture is a set of decisions that are hard to change. For a software project, these decisions are about the desirable characteristics of a piece of software. When you think about what is desirable for a piece of software, it is important to remember that the delivery of the first stable version of the software is only one milestone of its lifetime.

Continuous integration and continuous delivery

You must have heard of the terms continuous integration and continuous delivery. These approaches exist because change is continuous. Software can change for several reasons: new features might be needed because customers require them or because competitors already have them, bugs have to be fixed, computer platforms evolve, audiences grow, and legislation changes. So, customers, competitors, environments, and governments will force changes in software. We can have many doubts about the future, but one thing we can be sure of is that there will be changes.

Note

Jean-Marcel Belmont defines continuous integration as follows:

“[...] a software engineering task where source code is both merged and tested on a mainline trunk. [...] Continuous integration is continuous because a developer can be continuously integrating software components while developing software.” You can read more about this in Hands-On Continuous Integration and Delivery, Jean-Marcel Belmont, Packt Publishing.

Jez Humble and David Farley, in their book Continuous Delivery, Addison-Wesley, define this term as the release of new features of software as frequently as possible to reduce the risk that delivery carries.

A piece of software is a growing organism. Frederick Brooks, in his book The Mythical Man-Month, Addison-Wesley, states that there are four levels of complexity for software:

A program whose algorithm can be stored in only one human brain; in other words, only one person can understand it. It is a very specific program with a very limited task.

This kind of software serves specific needs and it is something that can be explained in a short conversation, although only the creator would be able to run and maintain it.

A programming product: A program that can be run and maintained by anybody with minimal documentation and that is readable by human beings.A programming system: A set of programs where one program is combined with other programs to perform more complex tasks.A programming systems product: Software that is nine times more complex and expensive than a single program whose logic fits in the head of a single programmer.

This software requires a big team to maintain it. It cannot fit in a single person’s head. It is not easy to explain how it works or how it is organized. But, according to Brooks, it is the aim of most software development efforts.

Note

The Mythical Man-Month is a classic text for software engineering. Although it was written before the rise of agile software development, its analysis of the complexity of producing software and the difficulty in parallelizing tasks remains current.

Complex software under continuous change requires some characteristics to be maintained for a long time. We are talking about software made to last and not to throw away after a week. Some software is ephemeral, so you do not have to worry so much about its structure. Automatic code generation tools are great for generating code that will soon be discarded. But software that will evolve requires a deep understanding of how software works. In fact, software made to last requires some key characteristics: minimal complexity, loose coupling, extensibility, and reusability. Each one of these desirable characteristics is related to one critical characteristic: ease of maintenance.

It seems contradictory to say that a complex system must have minimal complexity. In fact, when we say that a programming systems product is complex, we are talking about a system that has many parts and that is big. Minimal complexity refers to the internal organization of these parts and how they are connected. It is not expected that every member of the development team knows everything about the entire system at all times, but it is desirable that any member of the team can easily understand a part of the system so that they can change it when it is necessary.

Erich Gamma, when he was interviewed by Bill Venners, stated that current software environments are too complex to create applications without the reuse of existing code. Gamma presumes that OOP is the standard paradigm of development because it offers the extensibility that is essential to reuse. Gamma states that there are three levels of reuse in OOP: reuse of classes, reuse of patterns, and frameworks. He emphasizes that frameworks are the highest level of reuse because they identify the key abstractions for solving problems and offer implementations that contain the knowledge and experience of several developers.

Note

You can read the complete interview with Erich Gamma at https://www.artima.com/articles/erich-gamma-on-flexibility-and-reuse.

The usefulness of a framework

When you use a framework to develop a piece of software, you are not only reusing classes like you do when you use libraries. Class libraries are like outsourcing in software development. You use class libraries because you want to focus on specific business issues, not on general issues that someone has already solved. But you call the classes of a library. A framework works under Hollywood’s Law: Don’t call us, we’ll call you. The framework classes call your classes. It takes care of the general behavior of the software and lets you define the custom behavior. When you use a framework, it is like your software is a franchisee. Your software shares the same infrastructure that other software has. When a franchisor solves a problem or improves some feature of the business, it solves for all franchisees. When a framework offers a solution for a problem, it solves a common problem for all applications that use it. As the Dungeon Master says, The fate of one is shared by all.

We use a framework to make software easy to maintain. So, a framework has to help us to create code with minimal complexity and to reuse existing code with loosely coupled components. Once a framework implements design and architectural patterns, it provides a solution to generic issues, and so, in its evolution, it focuses on the improvement of generic solutions. Erich Gamma states that a framework provides default functionalities at a high level. The focus on the default issues of a piece of software allows that framework to be in control of an application, like a manager or an advisor.

When we see a great software developer like Mariano Iglesias speaking against frameworks, he is actually speaking against something else: frameworkitis. As Bill Venners had it in his conversation with Erich Gamma, this term means “the disease of wanting to make frameworks out of everything.” Erich Gamma says that some software named as frameworks actually wants to do too much for developers. The problem is that when they try to do it, they do so in a way that not all developers want and – even worse – in a way that developers cannot change.

A real framework must say, “Do not worry, I control your application and will take care of the generic issues for you.” A framework with frameworkitis, in turn, says, “Do not worry, I generate code and do everything for you in the best way and you do not need to change my implementation – in fact, you cannot do so.” Well, this behavior goes in the opposite direction of a constantly changing scenario. Frameworkitis takes developers from love to hate. First, they love a tool that seems to do everything for them, and then they hate the tool to which they are tied and that they cannot change. Thank goodness that Laminas is not like that.

From Zend Framework to Laminas

In the opening of the movie X-Men (2000), Professor Xavier says that mutation is the key to our evolution. He adds that mutation is how we have evolved from single-celled organisms into the dominant species on the planet. Software is like a living organism. It needs to evolve in order to survive. Sometimes it needs to change a lot and it seems like a mutation. The need for change requires that software allows changes. A hard-to-change piece of software is a candidate for extinction.

Evolution for a piece of software might look like replacing one component with another. A replacement may be necessary for the maintenance or improvement of scalability, performance, or security. But if it is hard or almost impossible to replace a component of a piece of software, the improvements will have to be made in a difficult way, usually by rewriting the existing code.

Patterns help with the replacement of components as components share the same patterns. If each development team of a company creates software using different patterns for components, it will be difficult to share components, prohibiting reuse, which is a desirable characteristic for software made to last.

My introduction to Zend Framework

In 2005, I joined a large IT company with several software development units. This company developed government software and had thousands of projects in various programming languages. The problem was that each team used different standards for their projects, so component reuse was virtually non-existent. In addition, there was a history of decisions made in the past by tools with low initial coding that in the long run precipitated technology lock-in. Several teams used frameworks, but each one of them used different frameworks for the same language. So, the difficulty in sharing components remained.

In 2007, I was working for a division that was prospecting for new technologies and my team had to choose a framework to standardize PHP application development in the company. By coincidence, that year a seminar on PHP frameworks took place in the city of São Paulo. We went to this event and attended three talks, each about a framework: CakePHP, Symfony, and Zend. I already knew CakePHP from the first PHP Conference Brazil and several colleagues from my company already used Symfony. Zend Framework, however, was a complete novelty for me. This should not be a surprise because the first stable version of Zend Framework was released that year. But it had been in development since 2005.

The audience reaction to the CakePHP and Symfony lectures was similar. When the speakers executed the commands in the terminal that generated code, the audience said, Wow! But in Zend’s talk, when they saw that there was no code generator, they were disheartened. The speaker listened to the complaints and replied that although Zend did not have code generation tools, it was quite flexible, not imposing too much. Helpfully, one of the spectators noted that the framework architecture seemed to be concerned with maintaining the application and not just creating it.

On the way out of the event, I heard several people saying that they would use CakePHP or Symfony, emphasizing the code generation tools. These people probably did not have in-depth experience in software development, or rather in maintaining existing software. There are other tools that help with code generation, such as integrated development environments. Frameworks are reusable and are tools for reusing code, not new code creation tools.

One of the speakers was selling a book with an analysis of five frameworks, including the three presented at that event. I bought it, read it, and conducted tests for those frameworks, implementing the same application with each one of them. Among the five frameworks analyzed, the one that had the best characteristics of minimal complexity, loose coupling, extensibility, and reusability was Zend Framework. It was largely configurable and did not prevent the use of components from other frameworks. At the time, the PHP Framework Interoperability Group (PHP-FIG) did not yet exist, but we needed tools that offered interoperability.

PHP Framework Interoperability Group

In 2009, at PHP Conference Brazil, some PHP speakers gave a lecture called PHP Framewarks. It was a joking reference to a “war of frameworks.” Each one of the speakers defended their favorite framework and attacked the others. Maybe there was not exactly a war of frameworks, but the fact was that once you adopted a framework, it was difficult to use the components of others because each one followed its own patterns. This scenario began to change in the same year, 2009, when a group of PHP experts met in Chicago, USA, for establishing specifications of components for the PHP community. This group was first called PHP Standards Group. The first specification was about an autoloading standard – what helps the emergence of Composer. In 2011, the group changed its name to PHP Framework Interoperability Group (PHP-FIG). Since then, members of awesome PHP projects have met to discuss and write specifications called PHP Standard Recommendations (PSRs). Several frameworks and other PHP applications have adopted the specifications of PHP-FIG.

Zend Framework – the reference architecture for PHP applications

Zend Framework allowed us to create a reference architecture for PHP applications that helped applications to evolve. An application can use internal components, which are within its structure and serve only it, or make use of reusable components, which are shared by several applications. A component can perform a task that extrapolates the responsibilities of the reference architecture pattern implementations or even replace the implementation of a layer (but using the same interface).

To solve a given problem, the software architect must first look for an existing component that solves it. If it exists, but does not meet all the requirements, the possibility of extending it should be analyzed. Only as a last resort should a new component be created. In this case, the component is born as an internal component to meet a specific application. But the component architecture must be treated as generic so that it can be later published and improved so that it becomes a reusable component. Zend Framework had a structure concerned with these issues.

The first stable release of Zend Framework was released before PHP 5.3, so ZF1 did not use namespaces. There was no Composer yet, so ZF1 had its own autoload implementation. But the one aspect that Zend Framework had present in its structure was, as I mentioned, the possibility to change. In fact, the unstable versions already brought configurable code like this:

Zend_Controller_Front::run('/path/to/controllers');

Instead of determining the directory for the controller classes, Zend Framework lets the developer choose. There was a proposed project structure, and today there is a Model-View-Controller (MVC) application skeleton available to start building an application, but the possibility to change the address of the project elements remains.

Another interesting feature of Zend Framework is recognizing that PHP applications already exist and you need to evolve what already exists. There will not always be demand for new projects, but what is in production needs to be maintained. Thus, Zend Framework allows from the beginning the use of components decoupled from the MVC implementation. Being able to refactor an application using Zend Framework components meant being able to outsource tasks that weren’t the focus of the application’s business without having to change everything. Change is necessary, but if it can be done slowly, gradually, and safely, it is better.

Zend Framework evolved gradually, keeping pace with the evolution of the PHP programming language and other software development technologies while incorporating design patterns and programming paradigms. In 2008, version 1.5 of Zend Framework incorporated the Two-Step View pattern with the Zend_Layout component and delivered a component to create dynamic forms, Zend_Form. In the same year, version 1.6 extended PHPUnit through the Zend_Test component. In 2009, Zend Framework gained a code generation tool, Zend_Tool, and a component for inversion of control, Zend_Application. IDEs such as Eclipse and Netbeans soon offered integration with Zend_Tool.

Even in its first major version, Zend Framework started to offer, even optionally, the possibility of creating modules. Modules, in Zend Framework terminology, are self-contained units that can be reused. Module architecture is well suited to complex systems that must be divided into several subsystems. In a world of microservices, modules allow you to create an initially monolithic application that can gradually be converted into a distributed system.

You might ask, Why don’t we just create an application using microservices? The answer is another question: Is that really necessary? Today, we have elastic resources with cloud environments, but that is not a reason to allocate resources that we do not need yet. We do not need to change in advance but be prepared for change. The cake has an adequate amount of time to bake.

In version 2.0, Zend Framework evolved the module architecture and improved the consistency and performance of the components. The code was refactored to use namespaces and two new components were incorporated: EventManager, a combination of several strategies for event-driven programming used by the MVC implementation, and ServiceManager, a container for dependency injection. Decoupling between components has increased significantly since version 2.0.

Version 2.5 brought radical changes to Zend Framework. Each component was given its own version control repository and had an independent lifecycle. In addition, the autoloading of classes and the installation of components is now done by Composer. Until version 2.4, Zend Framework was a download everything but just use what you want framework. As of version 2.5, it became a download and use only what you want framework.

Version 3.0 of Zend Framework updated the minimum dependency on PHP to version 7, taking advantage of improvements implemented in the language. In addition, Zend Framework 3.0 brought a special microframework for creating middleware, Expressive. This microframework was implemented in strong compliance with PSRs from PHP-FIG, with complete independence from the components to be used.

And that was the end of Zend Framework. Yes, that was the end of it, because as we said at the beginning of the chapter, it is now called Laminas. Lamina means blade. The reason for this name is that the framework allows the creation of applications in layers, but thin layers, that is, with minimum necessary layer size. As Professor X said, evolution is slow. But sometimes evolution leaps forward. The change from Zend Framework to Laminas required a refactoring of all class names. In addition, the technical and social infrastructure of the community also changes. But this leap was good, because a framework with so many years of experience is more open now. And you are going to learn it here!

The differences between Zend Framework and Laminas

There are some differences between Zend Framework and Laminas as regards the community ecosystem. Zend Framework, as an open source project, accepted code contributions. Laminas, in turn, can also receive donations because it is under a non-profit organization. Zend Framework had forums and a Slack channel for the community to have discussions and make contributions. Laminas, in addition, has monthly open-to-the-public meetings and keeps a record of Technical Steering Committee votes (TSC is a group of members with technical knowledge that governs the project). In other words, Laminas is more open to community participation and transparent than Zend Framework. This is good! You can - if you wish – participate actively in the development of a product that helps you to create object-oriented web applications with several design patterns built in.

Steve McConnell states that the choice of programming language is a key construction decision for a software project. The PHP community, in turn, states that PHP is especially suited for web development. But the programming language is only one of the aspects you need to worry about when creating and maintaining web application projects. That’s why we are talking about Laminas.

The technical and social infrastructure of the Laminas community

We will talk about many features of Laminas, but we will not cover everything, of course. The main reference source for Laminas is the official documentation, available at https://docs.laminas.dev.

Figure 1.1 – Documentation home page for Laminas

The Components and MVC options on the documentation home page are directly related to the content of this book. Laminas, however, also includes the microframework Mezzio – formerly known as Expressive – and API Tools, an API generator built in with Laminas components.

The source code of all components is available for download and contribution at https://github.com/laminas. You will find more than 100 repositories with mature components. On this page, you can open issues for fixing bugs or requesting new features – remembering that for features, the level of response you get will depend on the interest of the community. If you have an idea for improving an existing component or even for creating a new component, be encouraged to send an implementation and not only a specification. Contributing to a free and open source project is an awesome way to learn more about software development and can help you to become known by your peers, who can then become your advisors. The guidelines for contributing to Laminas are available at https://github.com/laminas/.github/blob/main/CONTRIBUTING.md.

Roger Pressman defines software as a combination of computer programs and documentation about those programs. People are also part of a piece of software’s documentation, because they often hold tacit knowledge that has not yet been converted into explicit knowledge. When documentation is not enough, we may need help from people, and a recorded conversation can become documentation. You can chat with people involved or interested in Laminas in the official discussion forums, available at https://discourse.laminas.dev.

You can report potential security vulnerabilities by sending a message to [email protected]. For information about the security policy of Laminas, read https://getlaminas.org/security.

You can get support from the community by opening issues and posting your questions on the forums; you can even solve issues yourself by extending components. But if you want on-demand consultative support or long-term support, you can think about the enterprise support of Zend Technologies. For more information about this service, read https://www.zend.com/products/laminas-enterprise-support.

After this overview of Laminas, in the next chapter, we will prepare an environment for developing with this framework.

Summary

Software is like a living organism: it is born, it grows, and someday it dies. We do not want our software to die early, of course. For this, we need to provide our software with characteristics that allow it to survive for a long time. In this chapter, we spoke about frameworks that help us to create reusable and easy-to-maintain software.

We touched on the history of Laminas, a free and open source framework for building PHP web applications. We presented its evolution and its proposal as a framework for evolving applications.

In the next chapter, we will prepare our environment to develop PHP web applications with Laminas.

2

Setting Up the Environment for Our E-Commerce Application

To build a house, we need various tools and materials. The more sophisticated the tools, the easier it will be to erect the house, and the better the materials, the longer the house will last. The same is true with software. Appropriate tools can help increase our productivity, and suitable components can make our software easier to maintain. In this chapter, we will set up the development environment for the example application that we will be building throughout this book: a virtual store that allows customers to be registered and buy products. The tools chosen are all free and open source software (OSS) with distributions for the most used operating systems in the world.

In this chapter, we’ll be covering the following topics:

Installing a generic PHP: Hypertext Preprocessor (PHP) environment, with a web server, PHP interpreter, and relational database management system (RDBMS)Two different ways to install and use LaminasInstalling an integrated development environment (IDE)—the Eclipse platformIntegrating Laminas-related commands into the Eclipse toolbarThe data models we will use in this book for our exercises

Specifically, the chapter will comprise the following sections:

Installing LaminasConfiguring the IDE—Eclipse for PHP developersIntegrating Laminas and EclipseManaging MySQL

Technical requirements

In this book, we use Laminas MVC 3.3.4, which requires at least PHP 7.4. However, support for PHP 7.4 ended in 2022, so it is recommended that you use at least PHP 8.0, but be encouraged to use PHP 8.1. You can get deadlines for PHP support at https://www.php.net/supported-versions.php.

For creating and running the code of this book, you will need at least a PHP interpreter, a web server, and an instance of MySQL/MariaDB (although you can use every database supported by PHP if you adapt the database script). There are several ways to install each software, and there are some packages that reunite them. XAMPP is a package that bundles the Apache HTTP Server, PHP, and MySQL/MariaDB. You can download XAMPP for Windows, Linux, or macOS from https://www.apachefriends.org/download.html. Since it can be used with most operating systems of the world, we adopt it as our default PHP environment. Moreover, XAMPP provides a control panel that allows you to easily start/stop Apache and MySQL. In the following screenshot, we show a sample of the XAMPP control panel for Linux:

Figure 2.1 – Window of XAMPP control panel

The home page of Apache Friends, the host project of XAMPP, has a short and nice video explaining the installation process: https://www.apachefriends.org/index.html.

XAMPP also brings a phpMyAdmin instance for managing MySQL databases. Once you have started Apache and MySQL through the XAMPP control panel, you can access phpMyAdmin at https://localhost/phpmyadmin.

We will use the command line sometimes. For avoiding the use of the complete path of the PHP interpreter in the terminal, you must add the directory containing the PHP interpreter to your PATH environment variable. PHP is inside the following path:

c:\xampp\php for Windows/opt/lampp for Linux/Applications/XAMPP/bin for OS X

After installing your PHP environment, you must install Composer, a dependency manager for PHP. You can download it from https://getcomposer.org/download. Put the composer.phar file in the same directory as the PHP interpreter. For Linux and OS X users, rename the file composer only and grant it permission to run. For Windows users, follow the instructions at https://getcomposer.org/doc/00-intro.md#installation-windows.

From now on, our workspace will be the htdocs folder of the XAMPP installation. We will create all our examples in this folder. Remember: when I am talking about workspace in this book, I am talking about htdocs. Make sure the htdocs