С симфони портировать будет затруднительно, очень мало общего между 1.х и 2, имхо, кроме базовых принципа роутинга, а релиз перенесли с конца 2010 на март 2011, что говорит, наверное, о том, что API далёк от заморозки. Хотя, если время есть, то можно начинать разрабатывать и на sf2, поиск того, что сломалось после очередного коммита весьма поспособствует изучению внутренностей фреймворка (уже с этим столкнулся)
Угу, если раньше вирт. хостинг был признаком «нищебродства», а впс «крутости», то теперь впс чуть ли не становится признаком нищебродства, а нормальный вирт. хостинг признаком эффективного распределения ресурсов (не тратим время разработчика на администрирование, а доверяем это профессионалам, причём, как правило, за меньшие деньги в итоге). Конечно, если проект не требует круглосуточного мониторинга и мгновенной реакции даже не на проблемы, а на признаки их приближения.
Посмотрите на Symfony (и на 1.4, и на 2, уж очень они разные, практически никакой совместимости), без этого, имхо, сложно иметь верное представление о «рынке» php-фреймворков. Это как судить, например, о рынке автомобилей полностью игнорируя существование Мерседеса и Феррари (никаких параллелей не имел в виду :) )
Абстрагируя, мы скрываем ненужные в данном контексте детали. В Друпале (да и в любой другой CMS/F) абстрагирование модели данных (и их представления, и ещё много чего) уже провели без нас (ноды, таксономия и даже код, хранящиеся в БД), нам надо или вписать свою задачу в неё, или, в лучшем случае, игнорировать (в худшем — с ней бороться, например, если нет возможности использовать БД). Для задач хорошо вписывающихся в эту абстракцию Друпал хороший выбор, но вот если не вписывается… Фреймворки же не ограничивают (обычно) нас никакой моделью данных, вернее архитектурой её представления (хотя могут быть заточены под определённую, например ActiveRecord), абстрагируя лишь такие вещи как роутинг, представление и т. п., причём, как правило, мы можем использовать только нужные нам части фреймворков, а вот с друпалом такое сложно реализуемо
>Drupal более универсальное решение для создания web-ресурсов, чем чистые фреймворки…
Он по определению не может быть универсальнее ;) Какие-то задачи в нём могут быть уже решены (управление контентом :) ), но то что ещё не решено в лучшем случае решается с теми же усилиями, что и в «чистых» фреймворках. CMS/CMF это более высокий уровень абстракции, чем FW, как FW более высокий уровень абстракции, чем «чистый» PHP. Может скажете, что Drupal более универсальный, чем PHP? :)
Насчёт ФС я упомянул, чтоб подстраховаться от нападок типа «последнему ночному билду ***fs всё равно 20 файлов, 200, 200000 или 2000000000 в каталоге, оно хранит их в ОЗУ» :)
Вариант 1: всё-таки использовать средства ОС, программа запускается по дефолту от имени текущего пользователя и можно легко средствами ОС управлять доступом на уровне ФС (в NTFS встроенные ACL — у вас ведь винда, судя по Visual? )
Вариант 2: сделать объект/иерархию объектов реализующих юзеров и ACL в отдельной подключаемой библиотеке, способ хранения инфы можно (и нужно) инкапсулировать, начать, например, с простых текстовых файлов, а затем, если нужно будет, перейти на БД, просто заменив дллку (общую для всех прог). А по идее такая дллка должна быть в винде/стандартных библиотеках visual c++, чтобы использовать внутри (а не запуск от имени) приложения стандартные средства ОС
2mifa: По-моему, вы путаете ситуацию «взять друга на работу» и «открыть с другом дело». С другом, по-моему, проще вести дело, чем с незнакомым «инвестором», особенно на условиях 50/50, когда нет решающего голоса ни у кого, т. к. есть множество «невербальных» способов влияния на него (с другой стороны у него они тоже есть, и не факт, что в конфликтной ситуации победит верное мнение, да ещё по объективным причинам). Главное до начала любых деловых отношений оформить их с другом так же, как оформляли бы их и с незнакомым человеком, чтобы не потерять, если что, одновременно и друга, и дело, а только что-нибудь одно.
Если с фреймвокром, да ещё это не была первой попыткой в жизни его (и вообще фреймворки) использовать, то очень странно, по-моему.
Насчёт построчно, погорячился, конечно, хотя на php4 писать бы точно не стал, а вот на 5.3 думаю много костылей наружу торчать не будет, хотя руку на отсечение не дам.
XML меня самого испугали, сам пользуюсь обычно куда более простым и компактным (тот роутинг занял бы у меня две строчки, а при желании и одну) YAML (симфони2 из коробки поддерживает минимум 3 вида конфигов, включая простой php-код, которым тоже частенько пользуюсь, когда не вижу смысла выносить что-то в текстовый конфиг). А формально в исходниках примеров ни слова про интерфейсы и контейнеры, видимо «магия» или утиная типизация (с DIC не разбирался ещё).
2kmike:
А команда на php писала свой продукт с использованием фреймворка или всё с нуля? Просто фраза «мы — на django, они на php» как-то некорректно смотрится. Не могу представить, что какую-то фичу на симфони (а там многое заимствовано и с джанго, и с рельс) делать на порядок(!!!) дольше, чем на джанго, кроме, может быть, каких-то очень специфичных, которые решили включить в код джанго, какая-нибудь авторизация через LDAP например.
Сам какого-то особого удобства у джанго не заметил, и при желании, имхо, можно написать практичеcки такой же фреймворк и на php, и чуть ли не построчно можно переписывать (если позволит синтаксис построчно, иначе, конечно, нужны будут костыли, но большинство их останутся, по-моему, внутри фреймворка) — python и php всё же схожи куда больше, чем, например lisp и php. Хотя, может быть, не понял удобства django, потому что практически не пользуюсь фичами python, такими как генераторы, например — пишу, в основном, не пользуясь «ситаксическим сахаром» и в итоге, наверное, мой код легко перенести на любой императивный язык с динамической (а то и статической) типизацией, где есть if, for, while и class :)
В методе класса его писать как раз не нужно, там пишут cls. Self пишут в методе объекта, в статических методах вообще ничего не надо. Хотя это всё не более чем соглашения, может ставить первым параметром, например, this и там, и там если так привычнее.
Да ладно, что там такого полностью непохожего на другие языки? Инфиксная форма записи выражения (не префиксная, как в Лиспе, или постфиксная, как в Форте), реализованы все основные алгоритмические и ООП конструкции, причём такими же словами, что и в большинстве других языков: ветвление — это if, цикл — while и for, класс — это class и т. д. Что ещё? А, логика зависит от отступов? :) Зато никаких холиваров на тему как располагать скобки: Р И более компактный код по сравнению со многими такими способами
Если пользоваться только спецификациями http и css в качестве источника информации, то многие вещи элементарно реализуемые на таблицах (навскидку прижатый к низу окна футер страницы и сайдбары реально одинаковой высоты) на дивах сходу кажутся вообще не реализуемыми без js, пока не подглядишь у кого-нибудь, что, например, имеет смысл вложить пару div'ов вложить в другой — обёртку, семантически лишнюю и по сути реализующую функционал tr при табличной вёрстке