Статьи

Создание PHP5 Framework: часть 1

Поскольку веб-сайты становятся все более динамичными и интерактивными, разработчики часто обращаются к платформам, помогающим быстро создавать веб-сайты и веб-приложения. Несмотря на то, что существует целый ряд отличных платформ, пользовательский каркас дает вам возможность легко настраивать каркас по своему усмотрению и создавать его еще быстрее — как вы уже знали бы его входы и выходы, прежде чем работать с ним. В этой серии руководств мы собираемся создать нашу собственную среду разработки PHP5! Давайте начнем с планирования нашей структуры и установим базовую структуру.

В этой серии мы создадим наш собственный PHP5 Framework с нуля. Framework будет включать основные функции управления контентом, и мы будем использовать его для создания веб-каталога для небольшой организации.

Надеемся, что по мере нашего продвижения вы улучшите, создадите и оптимизируете эту платформу, чтобы она лучше соответствовала вашим потребностям, однако в этих уроках мы стремимся создать простую платформу, которая будет работать и поддерживать веб-сайт.

В течение следующих нескольких недель мы рассмотрим следующие уроки:

  • Создание обработчика аутентификации, уровня абстракции базы данных и менеджера шаблонов
  • Объединение этих объектов
  • Использование инфраструктуры для управления контентом и поддержки нашего сайта
  • Создание фантастического дизайна интерфейса.
  • Разработка для процесса входа в систему раскадровки
  • Как рамки могут быть расширены и расширены

При создании любой крупной компьютерной системы, будь то настольное приложение, распределенная сетевая система или веб-приложение, всегда будут архитектурные проблемы, связанные с ее реализацией.

Шаблоны проектирования решают некоторые из этих распространенных проблем, и мы будем использовать ряд шаблонов проектирования при создании нашей Framework, чтобы гарантировать, что у нас есть качественная, гибкая, надежная и удобная в использовании платформа, подходящая для любых целей! В частности, в этом уроке мы рассмотрим шаблон Singleton и шаблон Registry.

Первым делом, чтобы начать создавать нашу платформу, является создание подходящей файловой структуры, такой, чтобы у всего было свое место. Помимо файлов, используемых в платформе, нам также необходимо предусмотреть файлы, относящиеся к веб-сайту, который мы собираемся создать с помощью нашей платформы. Большинство веб-сайтов и веб-приложений имеют:

  • Некоторые часто используемые функции / объекты.
  • Деловая логика.
  • Дизайн

Это дает нам отличную отправную точку, файлы, относящиеся к каждой из этих трех категорий, должны быть сгруппированы в отдельном разделе. Взгляните на структуру каталогов ниже, затем мы обсудим причины этой структуры.

Обратите внимание, что папка .settings и файл .project были созданы в IDE, которую я использую, и не должны присутствовать в вашем приложении.

Основные функции и объекты, такие как доступ к базе данных, аутентификация, обработка шаблонов, объекты отправки электронной почты, объекты анализа электронной почты, должны храниться в папке, называемой объектами, в папке PCARegistry. Это позволяет нам отделить логику от Реестра (который мы вскоре рассмотрим) от объектов, хранящихся в Реестре.

Далее нам нужно где-то хранить нашу бизнес-логику, то есть файлы, которые мы создадим и которые используют нашу инфраструктуру. Мы должны хранить эти файлы в папке, называемой контроллерами. Каждая основная функция, которую выполняет наш веб-сайт или веб-приложение (например, перечисление бизнес-каталогов, предоставление и управление контентом, предоставление галереи изображений и т. Д.), Будет отдельным контроллером, хранящимся в его собственной папке в папке контроллеров. Мы не собираемся использовать их в этом руководстве, но важно иметь структуру каталогов, чтобы мы знали, как она будет работать.

Дизайн сайтов и шаблоны должны храниться в папке скинов. Поскольку нам могут потребоваться разные дизайны (либо пользователи приложения / веб-сайта, которые мы создаем с помощью нашей платформы, могут выбирать из нескольких дизайнов, либо изменять дизайн в зависимости от сезона или специального события), каждый скин будет находиться в отдельной папке. ,

В основе нашей инфраструктуры лежат основные функции, такие как доступ к базе данных, аутентификация пользователей и т. Д. Реализуя шаблон проектирования реестра, мы можем хранить эти объекты централизованно, внутри реестра, упрощая его для нашей платформы и любой приложения, которые используют нашу структуру для доступа.

Шаблон проектирования реестра хранит и извлекает ссылки на объекты и работает аналогично телефонному справочнику: хранит и извлекает контакты. Мы будем использовать его для хранения этих основных объектов, общесистемных настроек и, в дальнейшем, любых других данных или информации, которые должны использоваться в системе.

Поскольку мы храним эту информацию централизованно, мы хотим, чтобы только один экземпляр этого объекта реестра был доступен в нашей среде, если бы было доступно более одного, то у нас возникли бы проблемы, когда мы ожидали определенный фрагмент данных или определенный объект должен быть в реестре, когда он фактически хранится в другом экземпляре объекта реестра. Чтобы решить эту проблему, наш объект Registry также реализует шаблон проектирования Singleton, который предотвращает доступ к более чем одному экземпляру объекта.

Ниже приведен код PHP для файла registry.class.php , мы вскоре рассмотрим, как он работает.

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
032
033
034
035
036
037
038
039
040
041
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
057
058
059
060
061
062
063
064
065
066
067
068
069
070
071
072
073
074
075
076
077
078
079
080
081
082
083
084
085
086
087
088
089
090
091
092
093
094
095
096
097
098
099
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
<?php
/**
 * The PCARegistry object
 * Implements the Registry and Singleton design patterns
 *
 * @version 0.1
 * @author Michael Peacock
 */
class PCARegistry {
     
    /**
     * Our array of objects
     * @access private
     */
    private static $objects = array();
     
    /**
     * Our array of settings
     * @access private
     */
    private static $settings = array();
     
    /**
     * The frameworks human readable name
     * @access private
     */
    private static $frameworkName = ‘PCA Framework version 0.1’;
     
    /**
     * The instance of the registry
     * @access private
     */
    private static $instance;
     
    /**
     * Private constructor to prevent it being created directly
     * @access private
     */
    private function __construct()
    {
     
    }
         
    /**
     * singleton method used to access the object
     * @access public
     * @return
     */
    public static function singleton()
    {
        if( !isset( self::$instance ) )
        {
            $obj = __CLASS__;
            self::$instance = new $obj;
        }
         
        return self::$instance;
    }
     
    /**
     * prevent cloning of the object: issues an E_USER_ERROR if this is attempted
     */
    public function __clone()
    {
        trigger_error( ‘Cloning the registry is not permitted’, E_USER_ERROR );
    }
     
    /**
     * Stores an object in the registry
     * @param String $object the name of the object
     * @param String $key the key for the array
     * @return void
     */
    public function storeObject( $object, $key )
    {
        require_once(‘objects/’ . $object . ‘.class.php’);
        self::$objects[ $key ] = new $object( self::$instance );
    }
     
    /**
     * Gets an object from the registry
     * @param String $key the array key
     * @return object
     */
    public function getObject( $key )
    {
        if( is_object ( self::$objects[ $key ] ) )
        {
            return self::$objects[ $key ];
        }
    }
     
    /**
     * Stores settings in the registry
     * @param String $data
     * @param String $key the key for the array
     * @return void
     */
    public function storeSetting( $data, $key )
    {
        self::$settings[ $key ] = $data;
 
 
    }
     
    /**
     * Gets a setting from the registry
     * @param String $key the key in the array
     * @return void
     */
    public function getSetting( $key )
    {
        return self::$settings[ $key ];
    }
     
    /**
     * Gets the frameworks name
     * @return String
     */
    public function getFrameworkName()
    {
        return self::$frameworkName;
    }
     
     
}
 
?>

Итак, как работает объект Registry и как он хранит наши объекты в хорошем состоянии?

  • Объекты хранятся в массиве.
  • Когда новый объект сохраняется в Реестре, включается файл класса, объект создается, а затем он сохраняется в массиве.
  • Объекты извлекаются путем передачи «ключа» объекта в метод getObject.

Как это предотвращает создание еще одной копии объекта Registry?

  • Конструктор является закрытым , что предотвращает непосредственное создание объекта.
  • Клонирование объекта вызывает ошибку.
  • Если нам нужен доступ к объекту из нашей Framework, и он не доступен напрямую для файла, в котором мы работаем, мы можем вызвать статический метод singleton (PCARegistry :: singleton ()), чтобы получить экземпляр реестра.

Имея готовую структуру для основных функций, которые мы добавим в следующем руководстве, давайте посмотрим, как мы получим доступ к Реестру, и начнем работу с нашей единой точкой доступа Frameworks, нашим файлом index.php.

Дружественные URL-адреса обычно доступны во всех формах динамических веб-сайтов и веб-приложений, и один из самых простых способов сделать это (и управлять контролем информации через нашу платформу) — убедиться, что все наши запросы страниц проходят через index.php файл. В следующем уроке мы создадим файл .htaccess для перенаправления запросов из приятного, удобного формата в формат, понятный нашему файлу index.php.

Код файла index.php приведен ниже. В данный момент это мало что дает, но позволяет нам все наладить.

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
<?php
/**
 * PCAFramework
 * Framework loader — acts as a single point of access to the Framework
 *
 * @version 0.1
 * @author Michael Peacock
 */
  
// first and foremost, start our sessions
session_start();
 
// setup some definitions
// The applications root path, so we can easily get this path from files located in other folders
define( «APP_PATH», dirname( __FILE__ ) .»/» );
// We will use this to ensure scripts are not called from outside of the framework
define( «PCAFW», true );
 
/**
 * Magic autoload function
 * used to include the appropriate -controller- files when they are needed
 * @param String the name of the class
 */
function __autoload( $class_name )
{
    require_once(‘controllers/’ . $class_name . ‘/’ . $class_name . ‘.php’ );
}
 
// require our registry
require_once(‘PCARegistry/pcaregistry.class.php’);
$registry = PCARegistry::singleton();
 
// print out the frameworks name — just to check everything is working
print $registry->getFrameworkName();
 
exit();
 
?>

Итак … что делает наш файл index.php в данный момент? Это:

  • Вызывает start_session сразу же, чтобы гарантировать, что мы можем использовать сеансы в рамках Framework (это нужно вызывать перед любым выводом.
  • Он создает определение текущего пути к файлу, поэтому мы можем ссылаться на корневой каталог frameworks из другого места, и он создает определение, которое мы будем использовать, чтобы гарантировать, что все файлы Frameworks вызываются из самой Framework, и что кто-то не ‘ пытаюсь вызвать один из файлов напрямую
  • Он использует функцию автозагрузки, чтобы определить, где могут находиться любые классы. В этом случае он указывает на каталог контроллеров, поскольку именно здесь будет храниться наша бизнес-логика.
  • Он включает в себя класс реестра (это необходимо, так как класс находится не в папке контроллеров, где его найдет функция автозагрузки, и ссылается на экземпляр реестра на переменную $ registry.
  • Наконец, он печатает имя платформы, чтобы продемонстрировать простую функцию из реестра.

Мы можем увидеть более подробно, как работает Реестр в нашей среде — создав несколько фиктивных файлов классов для его использования. Используя шаблонный класс в новом файле template.class.php в папке PCARegsitry / objects, мы можем продемонстрировать это, добавив дополнительный код в наш файл index.php.

В строке после первой ссылки на $ registry мы можем добавить:

1
$registry->storeObject(‘template’,’template’);

Если в нашем классе шаблона есть метод, содержащийся в нем, такой как generateOutput, мы можем вызвать этот метод из index.php следующим образом:

1
$registry->getObject(‘template’)->generateOutput();

Наша платформа теперь имеет базовую структуру, и у нас есть реестр для нашей основной функциональности. В следующем уроке мы рассмотрим создание объектов, которые будет хранить наш реестр, начиная с базового уровня абстракции базы данных и безопасности. менеджер.