Please read this section at least one day prior to the seminar. This section outlines what you are expected to know, be able to do, or prepare in advance. Following these instructions will help you get the most out of the seminar and ensure smooth participation.
Before the start of the practical, you should be able to:
include or require a PHP file.You can use OneCompiler PHP to test yourself before the lecture.
This slide applies to you only if you plan to use your own computer for the practical.
Before the start of the practical, make sure that:
We need all requests to arrive at the bootstrap script.
From there we can perform routing and dispatching.
A good practice is to put the index.php, the bootstrap script, into a public directory.
Note that you should already know this from the lecture, this is just a brief recapitulation.
There is an example of Front Controller implementations. The objective of the example is to demonstrates the idea. Do not use it as is for production nor in any of your projects.
Running with PHP build-in server is easy.
php -S 127.0.0.1:8888 -t ./public/
To test it out you can try the following script.
<?php
var_dump(\$_SERVER['REQUEST_URI']);
The Apache server must be configured to allow for use of .htaccess and rewrites.
webik.ms.mff.cuni.cz is configured in this way.
We need two files to make it work.
The first .htaccess file is located in root of your project.
It redirects all request to the public directory.
RewriteEngine on
RewriteRule ^$ public/ [L]
RewriteRule (.*) public/$1 [L]
The second .htaccess file is in the public directory.
It redirects requests to the index.php file.
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [QSA,L]
Keep in mind that files starting with dot '.', like .htaccess, are hidden by default on some systems.
public directory the file is served as is.
Otherwise the index.php handles the request.
The basic idea is about clear separation of responsibilities. Unlike the Model-View-Controller (MVC) the Model-View-Presenter (MVP) is less ambiguous.
Note that you should already know this from the lecture, this is just a brief recapitulation.
There is an example of Model-View-Presenter implementations. The objective of the example is to demonstrates the idea. Do not use it as is for production nor in any of your projects.
The design pattern expects existence of three code units / components.
The MVP may not always exist in 1:1:1.
There can be more Views rendered by a single Presenter. For example, HTML, JSON, etc..
It is common that part of the Model is implemented using object type focus interface. For example, model for working with events, orders, or customers. As a result, there may not be Model per Presenter.
What are parts of the web application, and how would you structure them?
Think of your application in terms of functionality units. Let us call them components. Keep in mind we are using the term very loosely here! A component is piece of code with well defined interface providing a functionality to the user or the rest of the application.
Put together a list of the components and their functionality. Focus not only on the user facing functionality but also internals of our application.
Continue to the next slide once you are done.
What application are we building? The application consists of several views:
How do we need to update the scaffolding to fit the application?
Continue to the next slide once you are done.
With all components and their responsibilities defined we can proceed to the next step.
First, we can define interfaces for the components. Remember that every interface should be extensively documented using comments. It is a good idea to consider type hinting as well. We deal with interfaces later.
Besides the interfaces we can draft the project structure, i.e. files and directories.
Continue to the next slide once you are done.
Congratulations, if you have followed the instructions, you have just reached the end of this exercise.
It is time to build the application step by step. Well or at least part of the application.
Front controller is the main entry point to the application. The Front Controller has two main responsibilities, routing and dispatching. Routing is about finding a piece of the application / component / controller / presenter which can handle the request. Dispatching is about passing the control to the component responsible for handling the request.
Think about what we need from each of them, what functionality, then design interfaces for each of them. Put each interface into a separate file, with respect to the proposed project structure from before. Ideas to consider:
With interfaces ready you can provide default / minimal implementation.
Continue to the next slide once you are done.
Design and implement list of events using MVP.
Introduce general Presenter and View implementation. Next introduce interface for List of Events View and Presenter. Introduce Events data access interface with a default hard-coded implementation.
Continue to the next slide once you are done.
Connect the FC and MVP together. Use the FC Router to select the List of Events presenter for path /events. Next utilize Dispatcher to let the presenter handle the request.
Continue to the next slide once you are done.
Congratulations, if you have followed the instructions, you have just reached the end of this exercise.
Where do we get the Router, Dispatcher, Model, ... ?
Note that you should already know this from the lecture, this is just a brief recapitulation.
There is an example of Component Manager implementations. The objective of the example is to demonstrates the idea. Do not use it as is for production nor in any of your projects.
The responsibility of this component, sometimes called application container, or container is to provide access to components.
This component can create instances of the components and perform their initialization. To do so this component is often provided with application configuration. As a result, the application can select the right data storage, e.g. JSON file, MySQLi based, etc.. Once the right implementation is selected it can provide the configuration to the component. For example, the data storage component can load the url, port, user, and password from the configuration.
Time to make our application even better.
Add component manager into your application and use it to get other components. As a result, there should be minimal use of new in your application as this is handled by the component manager.
Continue to the next slide once you are done.
The applications consists of 4 pages, see the list below.
We should already implemented the List of events. The Landing page is quite straight forward as well. Yet, the other two views both pose their uniq challenges. Try to finish as many as you can.
Continue to the next slide once you are done.
In order to get the bonus point you need to finish subset of the application. Once the application is ready upload all your files to the ~/public_html/php-application/ directory at webik.ms.mff.cuni.cz . The application must meet following criteria: