Limb3 - это Web Application Framework, состоящий из пакетов, где каждый пакет обычно содержит узкоспециализированный функционал. Каждый пакет более или менее независим от других пакетов, и для разрешения межпакетных зависимостей используется схема, принятая в PEAR. Более подробно можно узнать во введении в Limb3.

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

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

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

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

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

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

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

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

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

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

Подробнее о WACT можно прочитать в соответствующем разделе.

how_to_download_noheader

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

Вот, например, базовый пример использования пакета ACTIVE_RECORD:

<?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";
?>

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

Подробнее об этом, а также о списке наиболее часто используемых системных переменных, можно почитать в разделе о роли системных переменных в Limb3.

Если кратко, то для переназначения системных параметров в приложении, если длинно…то лучше на эту тему почитать раздел, посвященный конфигурационным скриптам

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

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

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

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

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

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

Поэтому, взвесив все «за» и «против», мы, на наш взгляд, нашли компромисс в виде функции lmb_require. Эта функция в случае подключения классов/интерфейсов, по сути, не производит включения PHP кода, а лишь внутренне помечает, что данный класс расположен в таком файле. Далее эта информация используется в _autoload хендлере lmb_autoload, как только данный класс понадобится. При подключении же PHP модулей эта функция работает аналогично include_once.

how_to_run_tests_noheader

Лучше всего начать с того, чтобы поделиться с community своими идеями. Сделать это двумя путями: через форум или через трекер.