Фремворк Limb

Отредактируйте страницу и нажмите «Сохранить». Прочтите справочную страницу для ознакомления с синтаксисом вики. Пожалуйста, редактируйте только в том случае, если планируете улучшить содержимое. Если вы просто хотите потестировать что-либо, воспользуйтесь специальной страницей: PlayGround.

====== Часто задаваемые вопросы по Limb3(FAQ) ======

===== Что такое Limb3? =====

Limb3 - это Web Application Framework, состоящий из пакетов, где каждый пакет обычно содержит узкоспециализированный функционал. Каждый пакет более или менее независим от других пакетов, и для разрешения межпакетных зависимостей используется схема, принятая в [[http://pear.php.net|PEAR]]. Более подробно можно узнать во [[limb3:ru:for_beginners|введении в Limb3]].
===== Разве не хватит фреймворков? Вы не придумываете еще одно "колесо" или Rails клон? =====

Проекту Limb уже более 4-х лет(на 2007 год). Мы появились, когда еще многих фреймворков просто-напросто не было. Первый официальный релиз Limb2 произошел весной 2004 года(однако работа велась около года и до этого), и на тот момент нас не удовлетворяло ни одно из существующих PHP решений для построения CMS(Content Management System). Два года использования выявили плюсы и недостатки Limb2, и где-то в конце 2005 года мы принялись за разделение кодовой базы на более узкоспециализированные пакеты. Полностью отказаться от Limb2 было бы для нас на тот момент сумасшествием, как, впрочем, и вносить столь радикальные изменения в существующий код. Поэтому было решено создать полностью отдельную ветку Limb3.

Ко всему прочему, мы предъявляем высокие требования к качеству кода. Практически 90% кода Limb3 покрыто модульными тестами, не всякий PHP фреймворк может этим похвастать. Мы используем agile методики в разработке: TDD, парное программирование, [[wp>Continuous_integration]] и проч.

На счет [[http://rubyonrails.com|Rails]], скажем честно, да - эта библиотека сильно повлияла на наше мировоззрение, и определенный функционал в Limb3 был сделан под влиянием Rails, например, lmbActiveRecord, lmbController. Однако, поверьте, Limb3 содержит и собственные уникальные решения: отложенная загрузка кода, инструментарий для инъекции зависимостей, модифицированный под наши нужны шаблонизатор WACT, средство для выполнения тестов из файловой системы и проч. Мы полагаем, однако, что Limb3 является более модульной и общей библиотекой нежели Rails, по крайней мере, мы к этому стремимся.

К тому же, мы поклонники PHP, невзирая на все нападки(порой справедливые), на этот замечательный язык программирования. Мы склонны думать, что и на PHP можно и **нужно** писать красивый код, который легко поддерживать и расширять. По крайней мере, Limb3 этому живой пример.

И последнее, Limb3 не накладывает на разработчиков никаких ограничений в вопросах интеграции с другими фреймворками. Наоборот, мы только рады подобной интеграции, например, в приложении работу с моделью можно осуществлять пакетом ACTIVE_RECORD из Limb3, поиск - средствами Zend_Search, а обработку изображений взвалить на плечи ezComponents.

===== Я не могу запустить Limb3, что мне делать? =====

Сама постановка проблемы не совсем верная: Limb3 - это не законченное приложение, это библиотека, с помощью которой строятся приложения. На счет того, что делать - изучать документацию и примеры приложений, построенных на Limb3
===== Где взять примеры приложений, построенных на Limb3? =====

Мы постепенно заполняем репозиторий новыми примерами приложений, например, мы положили код limb-project.com в общий доступ, там же, в репозитории, можно найти код примера простого магазина и корпоративного сайта. Все примеры доступны в разделе [[limb3:ru:codebits|CodeBits]].

===== Разве Limb3 не CMF(Content Management Framework)? =====

Нет, Limb3 - это Web Application Framework. На нашей практике уже достаточное количество проектов, сделанных на Limb3, не связанных напрямую с обработкой контента. Мы полагаем, что подобная ассоциация возникает из-за Limb2, который как раз и являлся CMF. Сейчас все идет к тому, что Limb2 будет просто еще одним пакетом Limb3.

===== Limb3 - новая версия Limb2? =====

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

===== Что такое WACT? =====

Вообще WACT - Web Application Components Toolkit(http://phpwact.org), но в рамках проекта Limb мы подразумеваем под WACT крайне гибкую и мощную шаблонную систему. Наше знакомство с WACT произошло в 2004 году, когда еще не было ни одного релиза и весь код находился исключительно в CVS репозитории. В связи с проблемами обратной связи с основным разработчиком WACT нам пришлось сделать форк шаблонизатора в Limb. С тех пор в оригинальном WACT произошло много положительных изменений, однако проблема обратной связи с разработчиками осталась. Время от времени мы синхронизируемся с наиболее полезными(на наш взгляд) изменениями в оригинальном WACT, однако перейти полностью на оригинальную версию у нас уже, наверное, не получится. WACT движется в данный момент в направлении, которое мы не разделяем, однако, кто знает, в будущем возможно все.

Подробнее о WACT можно прочитать в [[limb3:ru:packages:wact|соответствующем разделе]].
===== Где скачать Limb3? =====
{{page>:limb3:ru:how_to_download&noheader}}

===== Как использовать пакет Limb3 в своем проекте? =====

* Самое важное - настроить правильно include_path, включив в него путь до Limb3. Однако, если пакет был получен через Limb3 PEAR канал, делать этого не надо, т.к, скорее всего, путь до директории с PEAR пакетами уже автоматически выставлен в php.ini. 
  * Также стандартной практикой является подключение **common.inc.php** из пакета, который планируется использовать. 
  * Дополнительно стоит посмотреть документацию на пакет, возможны какие-то специфические особенности использования.

Вот, например, базовый пример использования пакета [[limb3:ru:packages:active_record|ACTIVE_RECORD]]:

<code php>
<?php
 set_include_path('d:/var/dev/limb3/' . PATH_SEPARATOR .
                  get_include_path());

require_once('limb/active_record/common.inc.php');

lmbActiveRecord :: setDefaultDSN(array('driver' => 'mysql',
                                       'host' => 'localhost',
                                       'database' => 'ar_test',
                                       'user' => 'user',
                                       'password' => 'secret'));
 class News extends lmbActiveRecord{}

$news = new News();
 $news->setTitle('Test');
 $news->save();

$all_news = lmbActiveRecord :: find('News');
 foreach($all_news as $news)
   echo $news->getTitle() . "\n";
?>
</code>

===== Для чего нужны системные переменные LIMB_* в Limb3? =====

В Limb3 выработалась определенная практика изменения низкоуровневых настроек при помощи использования системных переменных. Мы полагаем, что они являются самым простым способом установки глобальных параметров. Все системные переменные Limb3 начинаются со слова "LIMB_". Выбор названия, а также ее функциональное значение зависит от конкретного пакета.

Подробнее об этом, а также о списке наиболее часто используемых системных переменных, можно почитать в разделе [[limb3:ru:constants|о роли системных переменных в Limb3]].

===== Для чего используется setup.override.php? =====

Если кратко, то для переназначения системных параметров в приложении, если длинно...то лучше на эту тему почитать [[limb3:ru:setup_files| раздел, посвященный конфигурационным скриптам ]]
===== Почему вы не следуете стандартам названий классов, принятых в PEAR? =====

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

* Неуклюжее наименование класса с зависимостью от файловой системы.
  * Ошибка первоначального наименования класса может повлечь к массовым изменениям в файловой системе и названиях других классов.
  * Мы не сторонники длинных имен, как например Zend_Search_Lucene_Search_Weight_Boolean(**внимание:** мы ничего ни имеем против [[http://framework.zend.com/|ZendFramework]], даже наоборот, считаем модуль поиска одним из самых удачных из существующих для PHP)

===== Почему используется непонятная функция lmb_require вместо require_once? =====

В Limb3 используется специализированная версия require_once - lmb_require из пакета [[limb3:ru:packages:core|CORE]], которая учитывает специфику хранения классов в проекте Limb3, "один класс = один файл" и на этой основе позволяет загружать код классов отложенно через механизм _ _autoload. Использовать lmb_require в своем коде, использующем Limb3, совершенно необязательно, эта функция прозрачна и полностью аналогична встроенным в PHP require_once, include_once аналогам. Однако, если вы заинтересованы в отложенной загрузке кода, то к этой функции стоит присмотреться. К тому, же lmb_require поддерживает glob модификаторы, например:

<code php>
lmb_require('src/model/*.class.php');
</code>

===== Есть ли средства отложенной загрузки кода через __autoload? =====

Да, есть. Такие средства предоставляет пакет [[limb3:ru:packages:core|CORE]], а точнее функция lmb_require. В свое время у нас был соблазн полностью отказаться от явного подключения кода и полностью переложить эту функцию на механизм _autoload, однако очень быстро были выявлены недостатки:

* В коде стало непонятно, откуда именно, из какого пакета подключается тот или иной класс
  * Мы не используем схему хранения классов, схожую с PEAR, где путь до файла фактически отражается в названии класса, поэтому пришлось разработать крайне негибкую схему индексации всех классов
  * framework не должен навязывать обязательной зависимости от _autoload, у разработчика могут быть причины против использования подобной схемы или персональные предпочтения по ее использованию
  * Разработчик, возможно, больше предпочитает иную схему хранения классов, не по схеме "один класс = один файл", например, в виде модулей. В этом случае использование _autoload крайне затруднено.

Поэтому, взвесив все "за" и "против", мы, на наш взгляд, нашли компромисс в виде функции lmb_require. Эта функция в случае подключения классов/интерфейсов, по сути, не производит включения PHP кода, а лишь внутренне помечает, что данный класс расположен в таком файле. Далее эта информация используется в _autoload хендлере lmb_autoload, как только данный класс понадобится. При подключении же PHP модулей эта функция работает аналогично include_once.
 
===== Как запускать тесты для Limb3 пакетов? =====
{{page>:limb3:ru:how_to_run_tests&noheader}}
===== Готов помочь в разработке, как это сделать лучше всего? =====

Лучше всего начать с того, чтобы поделиться с community своими идеями. Сделать это двумя путями: через [[http://forum.limb-project.com|форум]] или через [[http://bugs.limb-project.com|трекер]].

Пожалуйста, введите код подтверждения, чтобы доказать, что вы не робот:

   ___   _   __  _   __  ____    ___ 
  / _ | | | / / | | / / / __ \  / _ \
 / __ | | |/ /  | |/ / / /_/ / / // /
/_/ |_| |___/   |___/  \____/ /____/

Пожалуйста, оставьте это поле пустым:

Сводка изменений

Примечание: редактируя эту страницу, вы соглашаетесь на использование своего вклада на условиях следующей лицензии: CC Attribution-Share Alike 4.0 International

Фремворк Limb

Инструменты пользователя

Инструменты сайта

Инструменты страницы