Комментарии 72
Спасибо, надо будет поковырять. Symfony всё же бывает излишним для простых проектов.
Здорово, хорошая демонстрация 5.3-стайла. Вот только как всегда, на большинстве шаред хостингах про РНР 5.3 можно забыть…
Насколько я заметил, качественные хостинг провайдеры поддержку 5.3 уже давно включили.
А вы со многими хостерами работали?
Это риторический вопрос? Если конкретный, то где-то с 10, не больше.
Конкретный вопрос, мне действительно интересно. Пока доводилось общаться только с хостингами, предоставленными клиентами, в основном что-то корпоративное, поддерживаемое клиентскими же силами и парой местных хостингов, ибо интересовал городской пиринг. Не могли бы подсказать пару приличных хостеров, у которых однозначно есть РНР 5.3 именно на shared'ных тарифах?
Мне тоже интересен этот список :)
Возьмите VPS и не парьтесь, стоит столько же, а профита больше.
VPS подразумевает бОлшьую квалификацию, расширение зоны ответственности. Хорошо если сайт чисто для себя или информационный, а если это сервис, оказывающий платные услуги и хранящий персональные данные клиентов?
Понятно, что большинство разработчиков способны поднять, скажем, AMP на Linux по ssh «чтоб работало», но вот, например, закрыть доступ извне для рута и/или сделать защиту от брутфорса требует уже более специфических знаний. Также как оптимальные настройки того же LAMP. Хостинг же предполагает, что его администраторы более квалифицированы и в обеспечении безопасности, и в тюнинге среды выполнения приложения, да и работают 24/7, а не 8/5.
Понятно, что большинство разработчиков способны поднять, скажем, AMP на Linux по ssh «чтоб работало», но вот, например, закрыть доступ извне для рута и/или сделать защиту от брутфорса требует уже более специфических знаний. Также как оптимальные настройки того же LAMP. Хостинг же предполагает, что его администраторы более квалифицированы и в обеспечении безопасности, и в тюнинге среды выполнения приложения, да и работают 24/7, а не 8/5.
Вы все-еще работаете с хостерами, которые на протяжении 2ух лет не могут обновить ведущую технологию?
Не знал о такой штуке. И вправду очень похожа на Sinatra. На PHP 5.3 конечно красиво всё получается.
На офф. сайте примеры немного хромают.
Во-первых, данные блога получаются ещё до того, как мы узнали, что запрашивается действительно блог, а во вторых $output .= '
'; немного перебор.
Это я к тому, любопытно, как рекомендуется этот самый вывод организовывать, если по правильному? Twig подключать?
$blogPosts = array(
1 => array(
'date' => '2011-03-29',
'author' => 'igorw',
'title' => 'Using Silex',
'body' => '...',
),
);
$app->get('/blog', function() use ($blogPosts) {
$output = '';
foreach ($blogPosts as $post) {
$output .= $post['title'];
$output .= '<br />';
}
return $output;
});
Во-первых, данные блога получаются ещё до того, как мы узнали, что запрашивается действительно блог, а во вторых $output .= '
'; немного перебор.
Это я к тому, любопытно, как рекомендуется этот самый вывод организовывать, если по правильному? Twig подключать?
require_once "views/template.php"; пойдет? Понятие «по-правильному» вы определяете для себя сами, исходя из требований разрабатываемого приложения.Сделайте что-то вроде
если не хотите Twig, Smarty или что-то ещё прикручивать. Хотя, по-моему, в большинстве случаев Twig лучше чем native PHP
function render($template, array $data) {
foreach ($data as $key => $value) {
$$key = $value;
ob_start();
require __DIR__ . '/../templates/' . $template;
return ob_get_clean();
}
$app->get('/blog', function() use ($blogPosts) {
$posts = $blogPosts; // тут может быть формирование массива из БД
return render('../templates/blog.php', array('posts' => $posts));
});<?php foreach ($posts as $post): ?>
<?php echo $post['title'] ?></br>
<?php endfor ?>
если не хотите Twig, Smarty или что-то ещё прикручивать. Хотя, по-моему, в большинстве случаев Twig лучше чем native PHP
Красиво выглядит. Сразу назрело пару вопросо:
— замыкания с hello world конечно хороши, а что делать если ножа что- то побольше? Станет не так красиво.
— неограниченный путь и колко параметров, а в каком фреймворке оно ограничено?
— замыкания с hello world конечно хороши, а что делать если ножа что- то побольше? Станет не так красиво.
— неограниченный путь и колко параметров, а в каком фреймворке оно ограничено?
В момент, когда станет совсем некрасиво, разработчику стоит задуматься о переезде на полновесный фрэймворк. Silex не создавался для разработки комплексных интернет-магазинов и социальных сетей — для этого есть Symfony2.
И какой кровью ему придется «переезжать»?
А что, вы уже собрались писать гигантский проект с сотней контроллеров и десятком бизнесс-объектов на Silex?
Если вы написали домашнюю страничку, а потом, вдруг, по мановению волшебной палочки решили сделать из него социальную сеть — вам в любом случае придется пересмотреть архитектуру контроллеров и роутинга. Но правильно спроектированные слои бизнесс-логики и представления могут переехать неизменными. О чем вопрос вообще?
Если вы написали домашнюю страничку, а потом, вдруг, по мановению волшебной палочки решили сделать из него социальную сеть — вам в любом случае придется пересмотреть архитектуру контроллеров и роутинга. Но правильно спроектированные слои бизнесс-логики и представления могут переехать неизменными. О чем вопрос вообще?
И все сервисы в Silex — простые PHP объекты, создаваемые через DIC. Переехать куда угодно когда угодно — не проблема.
Не только замыкания можно использовать, но и любую callable, как я понял.
Интересный фреймворк. Очень радует, что стали активно использовать phar.
DoctrineExtension уже в репозитории.
Я если честно не очень понял как компоновать приложение использую этот фреймворк?
Не в один же файл все запихивать?
Не в один же файл все запихивать?
Про Silex не скажу, но если он равняется на Sinatra — легко можно организовать подобие MVC.
<offtоp>
Лично для меня Синатра выглядит симпатичней все-же, не холивара ради :-)
</offtоp>
<offtоp>
Лично для меня Синатра выглядит симпатичней все-же, не холивара ради :-)
require 'sinatra'
get '/hi' do
"Hey there!"
end
</offtоp>
А в «этих ваших синатрах» тоже всё в один большой файл засовывается?
Извините, но вопрос не совсем понятен :-) Что значит «в один большой файл»? VC есть из коробки (вьюхи находятся в отдельных файлах, все изящно и красиво, можно использовать HAML. А насчет M — можно добавить ORM (DataMapper как отличный пример), отделить логику модели от контроллера… вот и получаем MVC. Но имхо все-таки Синатра больше подходит для маленьких проектов, для больших можно посмотреть в сторону Rails, там намного больше вещей «из коробки».
Я все делаю отдельно. Модели отдельно, нэимспэйсы (я использую экстеншен) каждый в своем файле, хелперы отдельно, вьюхи отдельно. в init.rb только конфигурация и загрузка остальных файлов.
Каждый роут можно обрабатывать в отдельном файле а в главном (index.php) собрать их все вместе.
Прелесть таких микрофреймворков в том, что они не ограничивают фантазию, т.е. выбор способа компоновки за вами.
It's up to developer. Как всегда, вообщем. Кто мешает разбить этот один файл на reusable controller groups: http://silex-project.org/doc/usage.html#reusing-applications или, допустим, вынести шаблоны в отдельный layer? Всего 1
require и у вас уже 2 файла. В чем проблема?1) банальные require/include в любом удобном месте
2) в качестве контроллера, как я понял, можно использовать любую callable, в т. ч. методы классов/объектов (Autoload идёт в комплекте)
3) $app->mount позволяет собирать приложение из других приложений по префиксу, то есть если уже есть приложение (экземпляр Silex\Application) $blog, обрабатывающее GET /posts, GET /posts/{id}, POST /posts, PUT /posts/id, то с помощью $app->mount('/blog', $blog), мы привяжем его к GET /blog/posts и т. д.
2) в качестве контроллера, как я понял, можно использовать любую callable, в т. ч. методы классов/объектов (Autoload идёт в комплекте)
3) $app->mount позволяет собирать приложение из других приложений по префиксу, то есть если уже есть приложение (экземпляр Silex\Application) $blog, обрабатывающее GET /posts, GET /posts/{id}, POST /posts, PUT /posts/id, то с помощью $app->mount('/blog', $blog), мы привяжем его к GET /blog/posts и т. д.
Хмм, смотрю, Sinatra, WebMatrix, Silex — видимо, популярность микро-фреймворков растет на каждой платформе.
В них круто то, что они и заявляются как «очень простые», там нет никакого «over-engineering» и народ не пытается раздуть из них что-то на все случаи жизни.
В них круто то, что они и заявляются как «очень простые», там нет никакого «over-engineering» и народ не пытается раздуть из них что-то на все случаи жизни.
Так а для каких целей они применимы? Я вот не пойму, где можно такое использовать
Идеальный вариант — прототипирование для последующего перехода на более «взрослые» фреймворки. Ну и для действительно небольших проектов (а точнее — для простых в плане логики).
Плюс — отличная вещь для начинающих разработчиков, чтобы не забивать голову сразу всем.
Плюс — отличная вещь для начинающих разработчиков, чтобы не забивать голову сразу всем.
Блог, сайт компании, сайт проекта. Вообщем вся мелочь, что сейчас за уши притягивается быть написанным на полновесном фрэймворке, после чего люди тонут в рутине фрэймворка, вместо решения реальных бизнесс-задач.
Или там где не хочется писать тот же REST роутинг с нуля (а для python/ruby чуть ли не веб-сервер с нуля надо писать), или там где full stack фреймворки слишком жёстко ограничивают, привязываясь к большой иерархии классов, не позволяя малой кровью сменить шаблонизатор, ORM и т. п., ну или просто слишком излишни/громоздки.
Сайты фотографов, портфолио, музыкальных групп. Да, у каждой уважающей себя группы есть сайт. Вот на народе миллионы сайтов — все они потенциально могут быть повешены на минифреймворк, что даст им интерактивности, которой нельзя добиться без серверного языка. А по сравнению с голым пхп оно будет смотреться опрятнее, а главное — будут обойдены многие грабли, с которыми иначе придётся столкнуться самому.
Для простых по структуре веб-сайтов с небольшим количеством роутов. Это не обязательно сайты-визитки. Простым по структуре можно считать, например, сервис микроблогов — всего несколько роутов. Или видеохостинг — то же самое.
При этом нагрузки на такие сайты обычно достаточно высокие.
При этом нагрузки на такие сайты обычно достаточно высокие.
Мне еще очень понравился gluephp.
Задача у него одна — роутинг.
Привязка URLов идёт к классам.
Недостаток для меня один — он больше ничего не умеет и нет возможности расширения (у разработчиков другое мнение, они заложили в основу принцип — «Do one job and do it well»).
Задача у него одна — роутинг.
Привязка URLов идёт к классам.
require_once('glue.php');
$urls = array(
'/' => 'index',
'/(\d+)' => 'index'
);
class index {
function GET($matches) {
if ($matches[1]) {
echo "The magic number is: " . $matches[1];
} else {
echo "You did not enter a number.";
}
}
}
glue::stick($urls);
Недостаток для меня один — он больше ничего не умеет и нет возможности расширения (у разработчиков другое мнение, они заложили в основу принцип — «Do one job and do it well»).
Там нечего расширять, ибо это не фрэймворк ни разу. Это простейшая, искуственно-ограниченная имплементация роутера.
Вопрос терминологии.
Сами они называют своё творение микрофреймворком, о чём и говорят на главной — «Glue is a PHP micro-framework.».
С таким же успехом можно сказать что Silex тоже ни разу не фреймворк а просто реализация роутинга и неких «сервисов».
Сами они называют своё творение микрофреймворком, о чём и говорят на главной — «Glue is a PHP micro-framework.».
С таким же успехом можно сказать что Silex тоже ни разу не фреймворк а просто реализация роутинга и неких «сервисов».
Ну и если уж говорить о терминологии:
«В отличие от библиотек, которые объединяют набор подпрограмм близкой функциональности, фрэймворк содержит в себе большое количество разных по назначению библиотек.» (from wikipedia).
GluePHP = роутер = один сервис = НЕ фрэймворк, а роутер
Silex = набор библиотек с service container'ом = много сервисов = фрэймворк
«В отличие от библиотек, которые объединяют набор подпрограмм близкой функциональности, фрэймворк содержит в себе большое количество разных по назначению библиотек.» (from wikipedia).
GluePHP = роутер = один сервис = НЕ фрэймворк, а роутер
Silex = набор библиотек с service container'ом = много сервисов = фрэймворк
НЛО прилетело и опубликовало эту надпись здесь
Doctirne2 там не будет: github.com/fabpot/Silex/pull/25#issuecomment-1010565. По крайней мере в виде оффициального экстеншена. Он там и не нужен!
Как по мне — лучше от таких «изваротов» разработчику не станет.
Реализовать привычный MVC можно в 45 киллобайтном PHP файле (пример code.google.com/p/green-framework/source/browse/trunk/system/Green.php). Зато затем можно будет легко портировать код под, например, CodeIgnitor или Kohana.
Реализовать привычный MVC можно в 45 киллобайтном PHP файле (пример code.google.com/p/green-framework/source/browse/trunk/system/Green.php). Зато затем можно будет легко портировать код под, например, CodeIgnitor или Kohana.
Ну примерно одну функцию выполняют да и, кажется, похожим способом. Только Silex даёт большую гибкость — использовать в качестве контроллеров, моделей и вью можно всё что угодно, ник чему не привязываясь (кроме роутинга). Ну и плюс REST фактически из коробки.
В основе Silex лежит service container. Все ваши и корневые сервисы являются простыми PHP объектами, не завязанными на сам фрэймворк. Можете переезжать хоть на друпал в любой момент.
Как только народ не изголяется, только бы рельсы не учить!
Казалось бы, причём тут рельсы в блоге о php-фрэймворке, не говоря о том, что symfony2 во многом рельсам не уступает, а в чём-то и превосходит…
Видели пантеру с гирей на хвосте?
Все эти нано-фреймворки с разной степенью успешности хотят (и стремятся) быть рельсами, но гиря на хвосте (в виде многословности php и непопулярности php reflections) ограничивает высоту прыжка
Все эти нано-фреймворки с разной степенью успешности хотят (и стремятся) быть рельсами, но гиря на хвосте (в виде многословности php и непопулярности php reflections) ограничивает высоту прыжка
В том-то и дело что «стремятся быть рельсами» не мини-фреймворки (Synatra же не стремиться стать рельсами), а у фулл-стэк получается ими быть хорошо, а в чём-то и лучше. Какой gem реализует паттерны DataMapper и UnitOfWork? То, что в руби гуглится по DataMapper, то только одно название, а по сути ActiveRecord.
Товарищи, а есть что нибудь вроде сайлекса., такое же развитОе, но для наших реалий? хостинг php 5.2+
может кому-нибудь сэкономит пару минут:
в ubuntu 11.04 столкнулся с тем, что пришлось дописать
в ubuntu 11.04 столкнулся с тем, что пришлось дописать
suhosin.executor.include.whitelist = phar в suhosin.iniЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Silex — микрофреймворк от создателей Symfony2