Lithium PHP Framework
Преди известно време се вдигна голям шум за това, че двама от lead разработчиците на CakePHP прекратяват дейността си по проекта. Голяма част от хората, които не просто използват Cake, ами се вълнуват от това, което става покрай него, изказаха големи притеснения относно бъдещето на фреймуърка. Въпреки това, преди няколко дни излезе файнъл рилийз на 1.3 и нещата поне на този етап изглеждат добре.
Паралелно с това се случи и нещо, далеч по-значимо за мен. Роди се фреймуърка Lithium. Още от самото начало се вдигна доста шум около него, който напълно логично намаля след време. В момента на публикуване на този пост Lithium е вече версия 0.9.5, тоест доста близо до заветната единица и стабилен рилийз.
Какво ви дава Lithium и дали е за вас?
Първото и най-основното нещо е, че повечето вече съществуващи фреймуърци, се пренаписват за 5.3, за разлика от Lithium, той е създаден изцяло с мисълта за 5.3 и благинките, които предоставя на разработчиците (да познахте, не поддържа PHP4 J).
За разлика от повечето фреймуърци, чието ядро и библиотеки имат доста малък процент code coverage, при Lithium нещата седят по съвсем различен начин. Още от самото начало на създаването на проекта, са използвани автоматизирани тестове. От Cake и CodeIgniter не могат да се похвалят с подобно нещо. Разработчиците са си написали собствен Test Framework, който получавате заедно с фреймуърка и лесно може да използвате за да тествате собствения си код (прилича доста на SimpleTest).
API-то е изключително чисто и приятно. Наложена е една последователност, която със сигурност ще ви допадне, ако сте подреден разработчик. Интерфейсът на библиотеките се учи за минимално време, благодарение на тази последователност.
Всички dependency-та са динамични. Така лесно може да екстендвате ядрото, както и да го конфигурирате така че да работи по специфичен начин. Наистина много полезно, ако ще правите форк за конкретните проблеми с които се сблъсквате в текущия проект, но и не само.
Ако сте CakePHP девелопър, със сигурност сте се сблъскали с Callback методите, които до голяма степен олесняват живота на разработчика. В Lithium те са доразвити по брилянтен начин с т.нар Filter system, която Nate Abele, толкова много спами 
Шегата на страна, ако да речем ви се налага да имате beforeSave и afterSave методи в модела и се налага afterSave метода да използва някаква информация от другия метод, ще се наложи да си разводнявате кода с променливи, допълнителни методи, масиви. Благодарение на филтър системата на Lithium това няма да ви се наложи повече, така бизнес логиката на приложението ви ще остане максимално изчистена. Звучи добре нали?
Конзолата е реализирана доста по-добре. Може да се екстендва без проблеми, като всъщност представлява едно приложение, което генерира цял проект, по специфично зададени темплейти, което преспокойно може да разширите и да накарате да генерира точно такъв код от какъвто имате нужда.
Това са само част от благинките на Lithium PHP Framework, съществуват още доста. Дали Lithium ще реши вашите проблеми или не, може сами да си прецените. Аз лично съм голям фен, грабна ме от самото начало (Марио Пешев може да каже, колко му мрънках в дения в който излизаше първия алфа релийз 
).
Прилагам и една много приятна презентация:
Изглежда интересно, но според мен тя и както всички PHP frame-ове не се целят където трябва.
Харесва ми че започват все повече да натискат за PHP5.3, но някак си все още ми се струва, че не се възползват от него както трябва. Много по Java-рски се опитват да направят нещата, а PHP е доста по-силен език от Java.
Радослав: „Изглежда интересно, но според мен тя и както всички PHP frame-ове не се целят където трябва.“
Ето един пример от tutorial-a им:
form->create(); ?>
form->field(‘title’);?>
form->field(‘body’, array(‘type’ => ‘textarea’));?>
form->submit(‘Add Post’); ?>
form->end(); ?>
Е защо да пиша $this-> ?
Друг:
Post Successfully Saved
?! Лично на мен ми харесва така:
Post Successfully Saved
Всеки нов PHP framework, прави същото като предния, само дет уж е по-тунингован „под капака“. Реално аз не работя „под капака“ и за това нищо не ме лови
Сори и това не е за мен
Радо, съгласен съм за Java-та, особено за Zend, а и отчасти за въпросния Lithium. Като сертифициран Java кодер не мисля да пиша PHP, ако ми дава същото, което прави Java. Въпреки че нещата тук стават доста по-rapid и по-леки, някои от фреймуърците добиват размер и маса, подобна на прасета като JSF или Struts.
П.С. Много обичам ООП, но в PHP все още ми е малко извратено всичко да е такова. Основно заради липсата на конкретни типове (валидация при компилация) и все още непълен autocomplete от IDE-тата.
Марио, за IDE си инсталирай NetBeans (http://netbeans.org/downloads/index.html) и няма да може да се оплакваш с непълен autocomplete
http://symfony-reloaded.org/
Всичко друго ще дойде и ще си отиде…
За нещастие малко PHP става както с JavaScript преди години, просто няма стабилна философия как да се пишат нещата. С последните промени в езика от все повече върви към Java, но някак си пак не му отива. Гледам сега новите PHP5.3 как веднага скочиха на новите функции там, но твърде по Java го правят ( в което няма нищо лошо, ако пишеш на Java ).
В момента постепенно минавам към Ruby и Rails и там нещата са просто в друга вселена. Просто не виждам който и да е PHP frame да може да стъпи и на малкия пръст на Rails в момента ( да не говорим какво ще стане като Rails 3 се появи ). Като и там фокуса не е да се прави нов framework всяка седмица, а в подобряване на това което вече е налично.
Но това си е мое мнение, може и да бъркам, може и не
php6:
$this->calendar->date(‘r’);
@Марто: това е Java FE (first edition
) 0.1 (alpha)
@Радослав: от както видяхме накъде се развива PHP повечето от нас, опитваме да забегнем към нови езици..RoR/Python са най-добрите алтернативи за момента
Скъпи колеги
Много от фреймуърците наистина се опитват да бъдат нещо повече от php фреймуърк – едни копират java, други ruby on rails, трети django, четвърти groovy on grails. Някак го намирам за нормално, като се има на предвид, че това са решения, които са се доказали във времето като работещи, нещо което поради една или друга причина не се е случило в php света.
@Любомир – писането на $this се прави с цел да не се получи конфликт между хелпъра и някоя променлива, носеща същото име, нещо което се добави на повечето фреймуърци в последните месеци, щото хората просто се осират, а повечето php фреймуърци не целят ученето на добри практики толкова, колкото да прилъжат по-голяма част от php програмистите
@Марио – в Литиум не видях нищо кой знае колко джавешко, което ме очуди, освен ако не търсим джава във всичко, тогава определено ще я намерим дори и в бийехвъра на микровълновата
@Радослав – за доразвиването на обекто ориентираната концепция, според мен все трябва да се върви към нещо, нещо работещо, както вече споменах. Езика няма посока, честно казано никога не е имал според мен.
@Марто – не мисля, че ще доживеем PHP6, наистина…
Колкото до Lithium – според мен това е най-доброто решение до момента. Ползвал съм, кажи речи, всички популярни php фреймуърци, като на 5-6 от тях разработвам проекти и до ден днешен. Това което е различно в Lithium и винаги се е усещало в предишните е, че те насилват да правиш нещата по тяхния начин, нещо което тук не е чак толкова изявено. В основата на това е динамик депендънси инджекшъните (с риск да се повторя от поста) и това че липсват плъгини, а има само адаптери. Искате propel? Имате propel. Искате twig? Имате twig. Искате custom Router – имате го. И всичко това без да се налага да барате и 1 ред от ядрото. Не обичам „магиите“ (automagic-а), обичам да държа всичко под контрол, обичам да знам какво се случва и обичам да го променя когато и както поискам.
Честно да ви кажа Lithium ми върна блясъка в очите, когато някой каже php, абсолютния пример, че нещата могат да стават дори и в език като PHP
Доживях php3, php4, php5… ще доживея и php6, друг е въпроса дали ще го преживея
Всички framework-ове имат недостатъци/ограничения – просто късно ги разбираме. Самото им название го подсказва frame work.
Цитат на деня: „Доживях php3, php4, php5… ще доживея и php6, друг е въпроса дали ще го преживея
“ 
Значи. Изглежда дооста приятно, подредено, добре структурирано. Силно ми хареса използването на Namespaces, всъщност това ми напомни, че не съм гледал новостите в php 5.3 и ще трябва да се запозная и с тях.
Обаче нищо не би ме накарало да сменя Symfony. Работя над 2 години с него и все още откривам разни неща в него и му се възхищавам силно.
В момента се задава версия 2, която ще е много по – лека и ще бие шамар на всички frameworks.
От известно време пиша главно 5.3 и честно да ти кажа дори бях забравил за наличието на namespace-ове, защото вече.. просто ги има
Колкото до Symfony, силно уважавам Fabien Potencier, той определено е един от хората в php света, който дава всичко от себе си нещата да вървят в правилната посока. Гледах бенчмаркове на Symfony 2 и останах впечателен от перформънса, макар че те съветвам да погледнеш тук, за малко по-достоверни данни на Paul M Jones, създателя на Solar PHP Framework (фреймуърк, който между другото харесвам много): http://paul-m-jones.com/archives/1222 
Но в крайна сметка със Symfony никога не сме се спогаждали добре, макар че използвам Twig и Doctrine ежедневно
Не е като да няма избор – http://superdit.com/2009/07/22/big-list-of-php-framework/
На мен ми изглежда като някакво извращение
@Калоян: Кое точно?
Имаш ли някое готово приложение на Lithium ? Интересно ми е примерно АРС ще се справи ли да кешира динамично зарадените класове (т.е. техните файлове)
Можеш да използваш това http://rad-dev.org/lithium_bin/source
Ще го гледам, сега бебет одокато ми дреме на шкембето мога само да базглеждам кода. Определено има неща които не ми харесват, и сега ще опитам да покажа какво имам предвид кога казвам, че е извращение.
http://rad-dev.org/lithium/source/libraries/lithium/action/Controller.php
Примерно ползването навсякъде само на един
Exceptionклас е супер назадничево, защото когато catch-ваш няма да знаеш какво точно да очакваш.Ето това също ме дразни, все едно в PHP няма възможност за различна видимост на методите (private, protected) — да го оставят да се гръмне само ако се опита да използва зашитен метод… или поне да се ползват Reflection информацията за този клас:
if (substr($action, 0, 1) == ‘_’ || method_exists(__CLASS__, $action)) {
throw new Exception(‘Private method!’);
}
Ами това – хващаш exception-а, за да го хвърлиш отново ? Ако има някакъв logging на грешката може, но там няма нищо:
try {
$result = $self->invokeMethod($action, $args);
} catch (Exception $e) {
throw $e;
}
Ех, че грозен стана коментара… ще смениш ли <code> със <samp>, а <pre> с <code>
Не очаквах просто че ще отпечата <code> като блок
И изтрий този коментар после, че само място ще заема
За exception-ите две мнения няма.
), знаеш за комплексарщината, за бенчмарковете в пхп фреймуърците, което е довело до компромиси на много места с устойчивата архитектура, нещо, което доста често виждаме, но някак го приемам за нормално вече. Личното ми мнение, е че най-големия недостатък е че като че ли е забравено за наличието на интерфейси в езика.
(между другото, радвам се че не си разгледал mysql адаптера, защото тогава нямаше да има какво да напиша 
)
Колкото до „проверката“ дали викания метод е прайвът/протектед, по мое му, в конкретния случай, няма да гръмне (http://pastium.org/view/2a368a9fd506da56547e99f3f6e281a3). invokeMethod е доста спорна идея, но самия факт, че на входа не проверява дали викания метод е публичен е достатъчно ясно, че идеята на създателите е била точно такава, ….та се принуждаваме да използваме наложената конвенция. Рефлекшъна е бавен (сега е момента някой да каже че и ООП е бавно, спрямо функционалното програмиране…
Но все си мисля, че ако тръгнем да търсим косури, може серия от блогпостове да направим. Имено за това гледам да подхождам оптимистично към новите неща и да се опитам да разбера какво повече ми дават и в кои случаи биха ми били полезни и какво мога да използвам от тях. Всеки фреймуърк е решение за определен тип проблеми, което е породено от виждането на група хора, ултимално решение все още няма. Поста беше по-скоро с цел презентиране на една различна гледна точка, а не толкова да твърдя, че това е топ решението без недостатъци, защото не е (по същия начин по който презентирах кодигнайтър, кохана, кейк и по който ще презентирам солар и прадо), дано съм останал разбран
Абе няма лошо в търсенето на косури, стига да са аргументирани — поне аз мисля така. Все още имам съмнения за динамичното зареждане, и дали bytecode cache ще успяват да кешират файловете, но трябва да го тествам защото пък от друга страна не вярвам да имат такъв голям недостатък, заради който да не могат да се ползват за „сериозни“ приложения.
Това с invoke-ването на action-а от dispatcher-а ми е фикс, понеже е едно от месатата в кода което се изпълнява най-често и влияе на производителността (както всичко от Front Controller-a). Решението, които смятам за близко до оптималното е да се слага префикс на action методите а ла „action_“ (както е май в ZF), ИЛИ да има добра дисциплина и в action controller-а да няма нищо друго освен action методи.
BTW, гледах тук за invokeMethod, който се вика от __invoke(), и май ако се опиташ да заредиш action метод, който е статичен ще пусне някой warning или notice а ла „Викаш статичен метод по не-статичен начин“. Ама това може би е малък пропуск заради младата възраст на проекта.
Иначе, SolarPHP ми е фаворит, нищо че Пол Джоутс е задник
@Кирил Ангов: В интерес на истината аз ползвам Netbeans и НЕ се справя отлично. В бетата има доста подобрения, но има още какво да се желае. Колкото до Symfony, както вече казах, никога няма да се намери ултимално решение, това че някой винаги ще използва един фреймуърк ми е малко консервативен подход, та определено ще има място за всички и да едва ли проекти от ранга на zend и cake ще си отидат току така. Дано само не се сецне Django, защото Фабиен Потенциер няма да има от къде да „търси вдъхновение“
@Кирил, и аз работя с NetBeans и Eclipse и и двете имат пропуски (поради некомпилируемия тип на самия език).
@Калоян К. Цветков: Той invokeMethod е „наследен“ от кейк и от идеята, че е по-бърз от call_user_func_array и в действителност съм го бенчмарквал преди време и даваше поне 2-3 пъти по-добри резултати. С apc каквто изпробвах – сработи. Колкото до Paul M Jones, защо смяташ че е задник?
Опитай се да спориш с него ;P
BTW, къде е този коментар на Кирил Ангов ? Не се вижда при мен
@Netbeans Бих предложил на всеки, който ползва Netbeans да отдели един ден да разучи в детайли какво е да имаш два проекта отворени vs един проект с include_path заложен в настройките на самия проект. Също така да махате директории, които не искате да участват в autocomplete-а. Това до голяма степен го подобрява за текущия проект. Също така още от времето на Zend IDE 5.5, на който смятам да твърдя, че Netbeans е достоен наследник, трябва да се пишат много точни коментари на функции и методи. И най-важното там е да има @return, за да знае едитора след като направиш $c = $class->getCriteria(), че това $c е релано class Criteria и да започне да ти допълва писането.
Това не бива да се прави
http://pastium.org/view/6807760494d746864749f121aeec9859
Две три такива неща трябват и 99% си ОК, което за мен е перфектно.
И въпреки всичко смея да твърдя, че Netbeans не може да се справи така, както се справя с джава, дори не е близо
Мога да ти дам прост пример с да кажем Кейк и масивът $uses в който пишеш кои модели искаш да използваш в текущия контролер. При $this->ИметоНаМодела–> не излиза нищо. А това е пример 1 от поне 100 случая 
Не бива да бъркаме проблеми на самия framework, с това как едно IDE прави code intellisense. Не мога да проверя лесно точно за кейк и този масив, но сигурно нямат добри коментари на класа и функциите. При симфони такъв проблем наистина няма. И тука не искам просто да опороча тази или онази, ноп разтършувай се из кода да видиш дали е така.
Момци, дискусията ви започва да става лек спор на религиозна основа, а това не е много приятно за едно приятно младо програмистко общество като вашето.
Аз искам главно да посоча как може да се направи кода лесен за IDE да дава точно autocomplete.
Веско, къде изчезна? Защо не публикуваш нищо ново?
На мен ми се струва, че кипи безмислен труд с тия нови и нови фреймворкове.
Ако няма нови и нови неща, сега още щеше да има една Партия и един Вожд. А php нямаше да има
Винаги съм бил фен на CodeIgniter и нямах намерение да пробвам нещо друго, но след тази статия почти се зарибих. Надявам се да е нещо доста по-добро от Cake-a.
Имаш мнение? Сподели го: