 |
|
|
|
Выбираем фрэймворк-среду для веб-разработки
Выбираем фрэймворк-среду для веб-разработки Вам не надоело в сотый раз клепать интерфейс к базе данных? В тысячный раз организовывать вывод таблицы с результатами некого запроса? Вы хотите сосредоточиться на более интересных задачах, не размениваясь на рутину? Тогда самое время задуматься о том, как от этой рутины избавиться. Использование фрэймворк-среды в веб-разработке – хороший способ повысить собственную эффективность, перестав отвлекаться на всякую ерунду. Паттерны проектирования, фрэймворк-среды, RAD – все термины из области разработки программного обеспечения ещё несколько лет назад редко можно было услышать применительно к веб-программированию. Это занятие большей частью считалось менее серьёзным делом, чем, например, разработка настольных приложений. Но время идёт, и при разработке современных веб-приложений уже трудно обходиться без профессиональных приёмов и инструментов проектирования. Одним из них является использование фрэймворков – каркасных сред для разработки приложений. Для языка PHP эти среды начали появляться относительно недавно, скорее всего под впечатлением от успехов Ruby on Rails – фрэймворк-среды для языка Ruby. Свою роль, конечно, сыграло появление пятой версии языка PHP, с «правильной» объектной моделью (большинство PHP-фрэймворк-сред написаны исключительно для пятой версии языка). В настоящий момент таких систем создано уже немало, и сегодня мы рассмотрим наиболее популярные из них. Зачем нужен фрэймворк? Надо сказать, это популярный вопрос среди PHP-программистов со стажем. Прежде всего использование фрэймворка ускоряет разработку приложений. Это достигается путём автоматизации стандартных (шаблонных) решений, предоставления различных инструментов для решения типовых (и не очень) задач, обычно оформленных в виде классов. Код, который пишется в рамках фрэймворка, более структурирован и унифицирован. Он удобен в сопровождении и легче поддаётся модификации. Пожалуй, главная причина, по которой стоит применять фрэймворк-системы – отсутствие необходимости изобретать очередной велосипед (вернее, целый парк таковых) на каждый новый проект. Вот лишь несколько взятых на вскидку проблем, которые решают фрэймворк-системы:
Все эти задачи вполне решаемы и давно решены (не по одному разу). Цель использования каркасных систем состоит в том, чтобы разработчик не разменивался на такие мелочи. При написании обзора не ставилась задача детально рассказывать о работе какой-нибудь конкретной фрэймворк-среды, производить их детальное сравнение я тоже не собирался. Скорее это представление и инструкция по началу работы с несколькими популярными средами этой ниши. Налетай на тортики! (CakePHP) Первой рассмотрим CakePHP. Это среда, известная с 2005 года, является сейчас, наверное, самой распространённой. Изначально написанная программистом Михаэлем Татариновичем (Michal Tatarynowicz), она сейчас активно развивается сложившимся сообществом. Для работы с CakePHP понадобится установленный на компьютере веб-сервер с модулем mode_rewrite (последнее не обязательно, но крайне желательно), интерпретатор PHP не ниже 4.3.2 или пятой версии. Также понадобится сервер баз данных (MySQL, PostgreSQL или любая СУБД поддерживаемая ADODB). Для установки скачиваем архив с программой с сайта www.cakephp.org, распаковываем на территорию нашего веб-сервера, переименовываем образовавшуюся папку во что-то более удобоваримое, чем cake_1.1.17.5612 (именно такая стабильная версия была доступна на момент написания статьи). После этого редактируем файл /app/config/database.php.default. В нём надо изменить следующие параметры: // используемая база данных var $test = array('driver' => 'mysql', // команда соединения (в данном случае можно // использовать 'mysql_connect' или 'mysql_pconnect' 'connect' => 'mysql_connect', // хост базы данных 'host' => 'localhost', //имя пользователя 'login' => 'geol', // пароль пользователя 'password' => 'superpassword', // название базы данных 'database' => 'cake', // название проекта 'prefix' => 'cake'); } После этого файл сохраняется с именем database.php, создаётся база данных с указанным именем (в данном случае «cake») и всё! Cистема готова к работе. Для проверки откроем в брузере url: http://localhost/cake. Если мы всё сделали правильно, должна открыться картина, как на рис. 1).
Рисунок 1. CakePHP установлена Ещё один важный момент – убедитесь, что в установленной среде для директории /app/tmp установлены права на запись для пользователя – веб-сервера. После инсталляции перед нами откроется дерево папок:
Назначение папок понятно из их названий:
Для того чтобы изменить размещение компонентов приложения, необходимо отредактировать файл app/webroot/index.php, поменяв в нём значение констант: if (!defined('ROOT')) { // путь к директории, которая содержит каталог приложения define('ROOT', dirname(dirname(dirname(__FILE__)))); } if (!defined('APP_DIR')) { // путь к каталогу приложения define ('APP_DIR', basename(dirname(dirname(__FILE__)))); } if (!defined('CAKE_CORE_INCLUDE_PATH')) { // путь к ядру CakePHP define('CAKE_CORE_INCLUDE_PATH', ROOT); } Зачем нужны все эти сложности? Прежде всего необходимо рассмотреть будущее предложение в аспекте паттерна MVC (Model-View-Controller). Реализация этой модели – это основная задача CakePHP, да и остальных PHP framework этого обзора (если вы тот самый, последний на этой планете разработчик, который не слышал о MVC, прочтите небольшой словарь терминов во врезке «Для тех, кто ещё не в теме»). В связи с этими же соглашениями нужно несколько замечаний по построению базы данных. Если у вас присутствует модель, например Item, ей должна соответствовать таблица базы данных Items. Это ещё не всё. В этой таблице обязательно присутствие первичного ключа, с именем id (ну кто бы мог подумать!), если таблице необходим внешний ключ, название поля должно быть вида tablename_id, где tablename – имя таблицы, на которую ссылается внешний ключ. Что такое модель в данной реализации MVC? Это не просто таблица базы данных, это класс (несколько классов), наследуемый от базового класса фрэймворка AppModel. Разумеется, мы можем посмотреть его реализацию, но гораздо легче представить этот класс как абстрактный (с оговоркой – насколько это возможно в объектной модели PHP 4). Реализация модели item будет сделана на основе такой конструкции: class Item extends AppModel { var $id; ... } Представление в CakePHP является обычным HTML-файлом, включаемым в PHP-код. Файл располагается в папке app/views/имя_модели/ и имеет расширение .thtml. Он представляет из себя обычный шаблон, снабженный некоторыми интеллектуальными функциями. Стоит обратить внимание на правила создания шаблона, описанные в руководстве. Но для самой элементарной логики надо знать одно – имена полей форм, реализующих запросы к модели, должны совпадать с именами полей таблицы базы данных, используемой моделью. Что у нас осталось? Мелочь – контроллер, отвечающий за бизнес-логику приложения. В данной среде он представляет собой класс, наследуемый от базового класса AppController. class UsersController extends AppController { function register() { ... } ... } Физически расположенный в директории app/controllers/, он принимает вводимую пользователем (посредством представления) информацию и реализует некоторое (в общем случае – любое) количество действий (в терминах PHP – методов). Сам процесс написания приложения заключается в реализации трёх вышеописанных компонентов и создании необходимых таблиц в базе данных. Надо заметить, что пока фрэймворк только осложняет нам жизнь, навязывая структуру программы. В этом есть доля правды – писать на основе CakePHP сайты-визитки или небольшие домашние странички действительно означает только усложнение жизни. Зато в сложных приложениях такое явное разделение компонентов MVC-модели принесёт только пользу. Да и к тому же ограничения закончились, теперь о вкусном. Прежде всего, это скаффолдинг (scaffolding – строительные леса, подмостки) – понятие, пришедшее из Ruby on Rails. Скаффолдинг – это возможность автоматически создать полный набор CRUD (Create, Retrieve, Update, and Delete)-операций (в данном случае стандартных форм с соответствующими кнопочками) и представления для любой таблицы базы данных. Она помогает быстрее начать манипулировать своими таблицами. Со временем вы можете постепенно заменить сгенерированные операции и представление своими собственными – которые, разумеется, будут намного красивее и функциональнее. Всё, что нужно для включения этого механизма в ваше приложение, – добавить в класс контроллера переменную $scaffold: class CategoriesController extends AppController { var $scaffold; } Скаффолдинг берёт на себя большую часть рутинной работы по созданию скелета приложения. О том, как его правильно настроить и использовать, читайте в соответствующем разделе документации. Что ещё? Хелперы (helpers) – встроенные функции, облегчающие работу с различными элементами HTML (в частности, с формами и таблицами), с объектами javascript, с асинхронными запросами (ajax) в представлениях. Основная их задача – автоматизировать рутинные операции, связанные с HTML-представлением вашего приложения. В самом деле – организовывать вывод из базы данных, в виде таблицы, причём с выделенными цветом чётными строчками – хороший пример рутинной операции, на которую не надо больше тратить время. То же самое (пусть и с оговорками) относится к проверке данных форм, впрочем хелперы могут тут помочь и при создании формы и при перехвате сообщений об ошибках валидации. Для работы с HTML CakePHP использует шаблоны, описанные в файле cake/config/tags.ini.php, вы всегда можете их изменить, предварительно скопировав этот файл в директорию app/config/ вашего приложения. Валидация данных – это всегда нудно, однообразно и, самое обидное, всегда необходимо. В CakePHP эта задача предельно облегчена. К хелперам, берущим на себя эту работу, прилагаются предопределённые константы, облегчающие процесс построения регулярных выражений для четырёх наиболее распространённых случаев такой проверки. Это VALID_NOT_EMPTY, VALID_NUMBER, VALID_EMAIL, и VALID_YEAR, названия констант говорят сами за себя, они определены в файле cake/libs/validators.php и не поддаются модификации (хотя есть обещание разработчиков о дополнении их функционала). Работа по валидации форм с применением этих констант выглядит приблизительно так: <?php class Item extends AppModel { var $name = 'FirstItem'; var $validate = array( 'itemname' => VALID_NOT_EMPTY, 'itemid' => VALID_NUMBER, 'email' => VALID_EMAIL ); } ?> Разумеется, ключи массива $validate в настоящем примере – это имена полей некой HTML-формы. Полный справочник функций хелперов вы можете изучить по адресу http://api.cakephp.org. Хелперы нужны для помощи в реализации представлений. Для помощи в реализации бизнес-логики, при создании контроллеров используются компоненты (расположены в папке /controllers/components). Это небольшие (как правило) общие мини-контроллеры, используемые обычно несколькими контроллерами приложения. Разумеется, есть возможность писать свои компоненты. Для этого создаётся файл /controllers/components/some_component.php, содержащий класс, наследуемый от класса object, методом которого передаётся в качестве аргумента ссылка на используемый контроллер. Примерно так: class FooComponent extends Object { function bar(&$controller) { } } Пример создания собственного компонента (из официальной документации): class FooComponent extends Object { var $someVar = null; var $controller = true; function startup(&$controller) { // This method takes a reference to the controller which is loading it. // Perform controller initialization here. } function doFoo() { $this->someVar = 'foo'; } } Теперь добавляем в код контроллера: var $components = array('Foo'); и вызываем компонент из кода контроллера: $ foo =& new Foo(); Коротко о других возможностях ACL-привилегии (ARO/ACO) определены в /app/config/acl.ini.php. Инструкции по определению доступа находятся в начале файла acl.ini.php. Инициализировать базу данных для ACL можно из командной строки выполнением следующей команды (из вашей директории /cake/scripts/): $ php acl.php initdb Работа с ACL в среде построена через обращение к объектам Aro() и Aсo() (Access Request Objects – объекты запроса доступа и Access Control Objects – объекты контроля доступа соответственно). Работа со списками доступа очень удобна и прозрачна, но подробно останавливаться на ней не будем. В документации приведены достаточно подробные примеры как назначения, так и проверки привилегий. На чём мы ещё не будем подробно останавливаться, но я обязательно упомяну? Прежде всего это сессии. Если кто-то из разработчиков не знает о сеансах работы или Sessions, данная статья пока не нужна, а всем остальным спешу сообщить, что работать с ними CakePHP очень удобно. Cake может сохранять данные сессии тремя способами (за это отвечает константа CAKE_SESSION_SAVE): как временные файлы в директории /Cake, используя механизм PHP по умолчанию, или использовать базу данных. Работа с сессиями происходит через компонент сессий, который, кроме базовых возможностей (чтение, запись), умеет сообщать об ошибках и процессах, обновлять сессию (с установкой нового идентификатора), оперировать с собственными сообщениями. Обязательно следует упомянуть кэширование представлений. Такую возможность CakePHP получила с версии 0.10.9.2378_final. По умолчанию кэширование отключено, при его активации (константа CACHE_CHECK в /app/config/core.php) среда будет хранить исходящие данные из обычных операций в кэше для ваших пользователей. При этом вы можете управлять содержимым кэша, например, указывать части представления, которые кэшироваться не должны, управлять временем кэширования. Пожалуй, стоит остановиться. За рамками описания осталось довольно много важного – верификация данных, шаблоны, управление запросами, механизм плагинов и компонент безопасности. Для ознакомления со всем этим богатством я ещё раз рекомендую ознакомиться с документацией на CakePHP, а также с очень интересной серией статей «Быстрое создание приложений на базе CakePHP», опубликованных на сайте IBM. Симфония с маленькой буквы (symfony) Первая версия среды symfony (пишется именно так, с маленькой буквы и ошибками) была выпущена в октябре 2005 года. Надо заметить, что писалась эта среда на PHP 5 и для PHP 5, поэтому при её использовании можно смело забыть о существовании четвёртой ветки. В основу этого фрэймворка его создатель Фабьен Потасье положил ORM (Object-Relationship Mapping)-библиотеку Propel, свои наработки в другом фреймворке – Mojavi, а также подход к работе с шаблонами из Ruby on Rails. Успешно стартовав, как основа для стратегически важного портала – сайта фирмы, торгующей нижним бельём, symfony был задействован в нескольких других проектах, после чего Фабьен открыл исходные коды системы, передав разработку сообществу. На образованном сайте проекта (http://www.symfony-project.com) можно наблюдать всё, что это сообщество натворило с фрэймворком на настоящее время (надо заметить и продолжает творить). Каковы основные преимущества symfony? Разумеется, среда представляет стандартные возможности, среди них – унификация доступа к базам данных, модульность структуры и, конечно, реализация модели MVC. К особенностям этого фрэймворка его разработчики относят простоту установки, хорошую совместимость с существующими схемами веб-разработки, возможность расширения за счёт интеграции сторонних библиотек. Поговорим ещё немного о «вкусностях» symfony. Среди возможностей среды такие «велосипеды», как встроенная поддержка многоязычности, фильтрация входных данных, удобная поддержка шаблонов и «хелперов» a la Ruby on Rails, автопроверка и автоматическая подстановка значений в формы при повторном заполнении. Мало? Тогда можно упомянуть об аутентификации, управлении доступом, кэшировании наличия классов для удобной работы с почтой. Должен добавить, что, говоря о лёгком в сопровождении коде, разработчики не кривили душой – в проект интегрирована библиотека phpDocumentator, позволяющая получить качественную документацию с наименьшими потерями сил и времени. Впрочем, за дело Сначала скачиваем sandbox («песочницу») symfony-среды с адреса http://www.symfony-project.com/get/sf_sandbox.zip. Почему песочница? Просто так мы получим уже созданный symfony-проект, включающий все необходимые и стандартные приложения. Так легче начать работать и освоить основные приёмы разработки. Как водится, распаковываем архив в корневую папку вашего веб-сервера. После этого (я исхожу из того, что установка производится на локальном компьютере) набираем в браузере url: http://localhost/sf_sandbox/web/frontend_dev.php и любуемся результатом. Если вы увидели страницу приветствия (см. рис. 2) – значит всё в порядке, если нет… Ну тут я теряюсь. Сделать что-то не так очень трудно.
Рисунок 2. Начало работы с symfony Для рабочего приложения среду лучше устанавливать через PEAR (да, да, symfony довольно давно доступна как PEAR-пакет), но для цели «попробовать» песочница идеальна. Кроме непосредственно symfony, мы установили и некоторые необходимые для работы библиотеки. Рассмотрим каждую из них:
Надеюсь у нас ещё будет возможность рассмотреть их подробно, но пока надо настроить среду. Разворачивание дерева папок и создание каркаса приложения я опускаю, поскольку в песочнице мы получим уже всё в готовом виде. А как это сделать при установке из PEAR или CVS (да, можно и так) подробно освящено в документации. Типовой проект приложения, предлагаемый symphony, имеет следующую структуру:
Назначение любой из этих папок вы можете узнать из документации по системе. Нам наиболее интересны папка apps/, содержащая папки приложений проекта (frontend and backend для интерфейса пользователя и администратора), папка config/ с настройками проекта и web/ – корневая папка веб-сервера. Типичная структура приложения выглядит следующим образом:
В данном дереве назначение папок cofig/, modules/ и templates/ не должно вызывать вопросов. В папке /i18n содержатся настройки для интернациолизации интерфейса приложения, в lib/ – специфические ресурсы. Структура типичного модуля:
Тут поясню, что в папке actions/ содержатся классы (как правило, один класс), реализующие все действия модуля. В папке validate/ находятся настройки, применяемые для проверок получаемых данных (например, проверка данных форм). Назначение остальных папок вопросов вызывать не должно. Структура веб-сервера (web/) достаточно типична для обычного веб-сайта. Вообще для создания рабочего приложения предусмотрены команды интерфейса командной строки. Выполнив: > symfony init-app app_name мы уже получим каркас типового приложения symfony. Каждое приложение, выполненное на основе среды symfony, представляет собой один или несколько программных модулей. Модульная структура – это основное отличие данного продукта от описанного выше (хотя над различием компонентной и модульной модели пусть ломает мозг кто-нибудь другой). Сам модуль представляет собой один или несколько скриптов (в одном или нескольких файлах), выполняющих родственные или взаимозависимые функции. Допустим, модуль «Каталог продукции» может отвечать за реализацию просмотра каталога продукции, просмотра описания отдельного товара (функции пользователя приложения), добавление товара в каталог, изменение сведений о товаре (функции администратора). Как symfony реализует MVC? Во-первых, эта модель несколько детализируется, а именно так:
Вкратце эта схема представлена на рис. 3 (взято из руководства «The Definitive Guide to symfony»).
Рисунок 3. Модель MVC в symfony Кажется, всё неправомерно усложнилось, но тут есть хорошие новости – писать отдельный скрипт под каждый пункт этой схемы не нужно. Всё гораздо проще – макет и центральный контроллер symfony сгенерирует сама. Более того, библиотека Propel способна автоматически предоставить скелеты классов модели и сгенерировать код с учётом схемы данных. При этом другая библиотека, Creole, берёт на себя абстракцию базы данных (для перехода с одной СУБД на другую достаточно изменить один параметр конфигурации). Как всё-таки начать работать? Для создания нового модуля, также подойдёт консоль, а именно команда: >init-module app_name module_name выполненная в папке проекта. После этого будет автоматически сгенерирован модуль с вышеописанной типовой структурой. В частности, будет создан файл actions/actions.class.php со следующим содержанием: <?php class mymoduleActions extends sfActions { public function executeIndex() { $this->forward('default', 'module'); } } ?> Тут у меня большое искушение прервать объяснения, так как дальнейший процесс создания модулей, страничек и приложений подробно освящён в документации (ссылки на которую даны в конце статьи), но хотелось бы освятить некоторые интересные моменты работы с классами в symfony – это хранители параметров и автоматическая загрузка. Хранитель параметров – это удобный способ скрывать атрибуты класса, которые задают необходимые параметры. Используется этот механизм следующим образом: $response= new sfResponse(); $response->getParameterHolder()->set('foo', 'bar'); echo $response->getParameterHolder()->get('foo'); => 'bar' Или с использованием специальных методов: $response->setParameter('foo', 'bar'); echo $response->getParameter('foo'); => 'bar' Для того чтобы созданный вами класс мог использовать хранитель параметров, следует добавить его к новому классу: class MyClass { protected $parameter_holder = null; public function initialize ($parameters = array()) { $this->parameter_holder = new sfParameterHolder(); $this->parameter_holder->add($parameters); } public function getParameterHolder() { return $this->parameter_holder; } } Известно, что в пятой версии языка PHP появилась очень удобная (и по началу очень нестабильно работающая) функция __autoload(). Symfony использует этот механизм на полную катушку. До такой степени, что просто отпадает необходимость в использовании операторов requaer/include! Вы можете смело писать код вида: $fooObject = new MySuperClass(); и, если MySuperClass() определён в любом из файлов, лежащих в папке /lib, будет осуществлена его автоматическая загрузка. Причём для увеличения производительности после сканирования директорий и загрузки нужного кода, он кэшируется для следующих вызовов в ассоциативном массиве. Подведём итоги Мы рассмотрели две, пожалуй, наиболее популярные фрэймворк-среды. На самом деле их гораздо больше. Из самых известных, безусловно, представляют интерес Seagull PHP Framework, FUSE и, конечно, Zend Framework – продукт от разработчиков ядра PHP. В будущем постараемся поговорить об особенностях этих систем. Приложение Для тех, кто ещё не в теме (основные термины, используемые в статье) Framework (Software Framework) – каркас программной системы, обычно включающий в себя библиотеки вспомогательных программ и сценариев, решающих типовые задачи и организованных как набор компонентов. Основное отличие фрэймворка от библиотеки в том, что эта среда сама исполняет код, а не используется в процессе выполнения. Фрэймворк может включать в себя набор библиотек. MVC (Model-View-Controller) – архитектура приложения, позволяющая выделить независимые фрагменты кода программы, отвечающие за состояние предметной области и бизнес-логики (Model), представление (View), и контроллер (Controller), отвечающий на действия пользователей и вызова изменения соответствующие модели или представлению (см. рис. 4).
Рисунок 4. Архитектура Model-View-Controller Основной принцип этой архитектуры в отсутствии непосредственного взаимодействия модели и представления. По идее они вообще не должны ничего знать друг о друге и общаться только через третий компонент – контроллер. В самом простом виде MVC можно рассмотреть на примере интернет-магазина, где модель – база данных товаров и пользователей (возможно, со своими хранимыми процедурами, функциями и тригерами|). Представление в нашем примере – это страничка, которую посетитель магазина видит в своём веб-браузере. Их может быть любое количество, скажем, браузеры для PC, для мобильных устройств, для приставок или, возможно, синтезатор речи. Контроллером тут будет веб-приложение, размещённое на сервере, реализующее взаимодействие интерфейса магазина и предметной области (технология и особенности его реализации – уже совершенно другой вопрос). ORM (Object-Relationship Mapping) – методика преобразования сущностей базы данных в объекты, оперируемые приложением. Проще говоря, подобный подход позволяет рассматривать таблицы и поля базы данных как объекты и методы языка реализации разрабатываемого приложения. Технологии, осуществляющие это преобразование, впервые появились в языке Java (Hibernate). В PHP ORM реализовывалось в PEAR::DB_DataOobject, а также в таких продуктах, как EZP-DO и Metastorage. ACL (Access Control List) – схема разграничения доступа для перечня субъектов или объектов, а также их групп (ролей), с соответствующими разрешениями или запретами к данным и функционалу системы, с использованием списка доступа. Список определяет, кто или что может получать доступ к данному объекту и какие операции позволено проводить над объектом. В типичных реализациях ACL каждая запись определяет субъект воздействия и действия, доступ на которые есть у субъекта. В модели безопасности, основанной на запросе, субъектом выполнения операции над объектом, система сначала проверяет его права на выполнение этой операции, а затем в зависимости от результата проверки позволяет или не позволяет выполнить операцию. PDO (PHP Data Object) – технология, появившаяся в PHP, начиная с версии 5.1. Применяется для унификации работы с базами данных. Расширение не делает ничего сверхъестественного в плане технологии (для любой базы данных необходимо установить свой драйвер при сборке PHP (--with-pdo-mysql, --with-pdo-pgsql, или --with-pdo-oci), но теперь нет необходимости применять свой набор стандартных команд для каждой СУБД. Судя по тому, как развивается следующая ветка интерпретатора – PHP 6, «родные» расширения для работы с различными базами данных будут вообще вынесены из дистрибутива. PEAR (PHP Extension and Application Repository) – библиотека классов PHP с открытым исходным кодом. В стандартную поставку PHP входит система управления классами PEAR, которая позволяет легко скачивать и обновлять их. Основная цель проекта PEAR:
ADODB – это библиотека абстрактных классов, написанная на PHP и Python, основанная на некоторых концепциях от Microsoft's ActiveX Data Objects. Она позволяет разработчикам писать приложения максимально правильно с точки зрения концептуального подхода к работе с хранилищами данных. В результате у разработчика появляется возможность изменить СУБД без необходимости вносить исправления в программный код приложения. YAML (YAML Ain't Markup Language – «YAML – не язык разметки») – создан как некоторая альтернатива XML. Проблема XML – сложность редактирования и чтения текста человеком. YAML решает ту же задачу, что и XML, то есть представление произвольной сложности структур данных, но в форме, удобной для человека, такие же аналогии можно провести между HTML и WikiWiki-разметкой.
|
Кирилл Сухов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
