Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
как вы думаете, кто-то бы стал тратить деньги и усилия на бесплатную для всех энциклопедию? там кроме рекламы, пиара и общеизвестных знаний ничего нет.
Что угодно! Например, на старых сайтах narod.ru (т. е. на тех, которые созданы до принудительного объединения с narod2) сервер после </html> цепляет это:
А на pochta.ru код ещё страшнее (лень копировать). Самое главное, что браузеры всё, что вставлено после </html>, интерпретируют, как будто тегов </body> и </html> не было.
Битрикс уныл и тяжёл - мне сложно представить что бы я его в проекте каком-нибудь юзал.
Я в основном юзаю, оооо внимание реклама http://www.zmicron.org - тада =)
Компоненты есть простые (почему бы и нет если они ускоряют разработку), а есть и не очень простые (запуск процессов в backgound http://www.zmicron.org/?q=coms/bglancher).
Прежде чем что-то говорить в код движка глянь... проффисионал блеать 🙂
Мне сложно сравнить этот фрейморк с FatFree, я его видел из-за статьи на хабре, но ничего на нём не написал.
Для меня micron проще, и работает хоть по очень упращённой но HMVC модели.
Так же в нём можно отдельно для каждого компонента создавать свой <head> в котором прописывать css и js например, после чего либа ExtraPacker все равно сольёт все это в 1-у css и js-ку. Вообщем удобно то, что не только логика и шаблон разделены и еще и css и js файлы этого кусочка шаблона тоже, есть header_footer-ый шаблон сразу, да и код простой до безумия - открыл index и понял за 10 минут все.
Но все это мелочь на самом деле - просто он не плох, раньше я за частую брал CodeIgniter для простых и Kohana для сложных, а теперь почти всегда на micron-е сижу и вроде как хватает...
привести аргументы вы так и не оказались в состоянии.
> Для меня micron проще
для вас проще потому, что вы его и написали.
> хоть по очень упращённой но HMVC модели
а что такое "очень упрощенная HMVC модель"?
> Так же в нём можно отдельно для каждого компонента создавать свой <head>
вот это уже понравилось
> есть header_footer-ый шаблон сразу
а зачем? во-первых, вы утверждаете, что у вас HMVC, что противоречит с данным утверждением (если только вы как раз это и понимали под HMVC), во-вторых, очень ограничивает в возможностях.
Поясню: например, мне нужно на всех страницах выводить не хедер и футер, а сайдбар - скажем с приветствием навигацией. Причем, приветствие не на всех страницах одинаковое. HMVC подразумевает, что я могу во view шаблона вставить подключение view сайдбара, но это не хедер и не футер.
> - открыл index и понял за 10 минут все.
этим и ограничивается документация?
> CodeIgniter для простых и Kohana для сложных
странное разделение:
1. кохана - это форк CI,
2. разве CI еще не умер?
> привести аргументы вы так и не оказались в состоянии.
ну сложно сранивать с тем на чем не работал - потому аргументов и не привел
> хоть по очень упращённой но HMVC модели
под hmvc я имел ввиду компонентная модель mvc и так действительно она сделана, однако по сути ф-я IncludeCom там делает просто несколько require файлов: языкового, контроллера и шаблона, без например CI-шной передачи параметров во вьевре, просто require подрят
> есть header_footer-ый шаблон сразу
А вот под этим я видимо не то имел ввиду, что вы. Попробую пояснить, что хотел сказать 🙂
Очень часто на страницах есть одинаковый шаблон, так вот он может быть занесён в общий template (tpl/main_template.php). Тогда получается такая ситуация например вызывается страница http://www.example.com/users выполняется контроллер users (он может вызвать еще кучу контроллеров, например для прорисовки каждого юзера и пр.) потом получившийся контент (если соответсвующий конфиг еще включен) будет выведен через tpl/main_template.php что бы вывестить в основной "рамке" сайта, а этот main_template.php может вызвать и кучу других контроллеров например сайтбар и навигацию и пр.
Т.е. сам по себе код может быть например таким:
вызываем http://www.example.com/users тогда движ подключает:
1) src/users.php:
$page = Get('p', 1);
$um = new UserModel();
$users = $um->GetList($page);
2) tpl/users.php // здесь будут доступны все переменные которые были в src/users.php, пример без шаблонизатора, так что не ругайте )
<head>
<link rel="stylesheet" type="text/css" href="<?= Root('i/css/users_list_design.css')?>" />
</head>
<div class="users">
<?php foreach ($users as $uid => $u)
{
// Тут включиться src/one_user, tpl/one_user которая тоже может свои css/js содержать
IncludeCom('one_user', array('user_id' => $uid)); // можно переменные в компонент вставлять
}
?>
</div>
Т.е. в примере хотел показать что сама по себе старница users это компонент который может вызвать другие компоненты причем в конце концов весь сбуферизированный контент можно будет вставить в главный шаблон сайта (если нужно конешно) а сделается примерно вот так (чутка по другому в реальности, я так для упрощения):
ob_start();
IncludeCom($_GET['query']); // в query например users может быть
$content = ob_get_clean();
IncludeCom('main_template', array('center_page' => $content)); // в tpl/main_template главный хед и боди сайта наример
> открыл index и понял за 10 минут все.
С докой действительно пока беда, как и с набором компонентов есть нормальные:
например рассказывающие о простой дефолтной модели: http://www.zmicron.org/?q=coms/def_model
а есть которые вставил чисто что бы инфа под рукой была (дефолтная ксс-ка для оконной рамки)
> CodeIgniter для простых и Kohana для сложных
Кохана с 3-ей версии уже не форк был, сейчас отдельно ветки 2-ая (форк CI) и 3-ая которая целиком с 0-ля.
А CI все еще жив, не так давно даже обновлялся в англ сигменте 🙂
Ну а вообще в нём много удобных вещей, которые при этом не сложно заменить:
1) включен уловитель ошибок Debug_ErrorHook (от dklab)
2) при желании можно скачать в компонентах дефолтную модель которая как бд юзает DbSimple и профайлер
3) есть XDebug профайлер для отлова, тож в компонентах
3) куча визуальных плющек подключаемых, например слайдер jquery-tools (тож в компонентах)
Подключается в нужное место вот так:
<?php IncludeCom("slider_head")?> // js и css (потом солются в одну)
<?php IncludeCom("slider", array("panels" => array("test 1", "test 2", "test 3")))?> // контент панелей
Просто не всегда надо и потому сам движ по дефолту пустой.
ясно, простенький велосипед для тех, кто не осилил Зенд или Кохану.
наверное, несложные проекты летают, но для более серьезных есть минусы:
1. функции и переменные определены глобально
2. шаблон (layout) один для всех
3. многие вещи, как, например, загрузка классов, все равно приходится дописывать самому
+. а где руты, работа с базой, проверка и фильтрация данных и т.д.?
кроме того, всякие эти котеровские "уловители" морально устарели.
лично я сейчас переписываю свой двиг, основываясь на следующих принципах:
1. Компонентная модель: в одной папке компонента (и подпапках) находится все, связанное с ним - код, шаблон(ы), стили, скрипты, конфига, языковые файлы и т.д.
1.2. Именование и расположение классов соответствует Zend Naming Conventions (Класс Package1_Package2_Class находится в /Package1/Package2/Class.php)
2. MVP и Passive Template - вид и поведение компонента определено в шаблоне (Вид), а не в контроллере, при этом управляющего кода в шаблоне нет.
2.1.Зато есть связанный с ним Обработчик(типа Контроллера), который реагирует на ввод (подача формы), но изменяет только Модель
2.2.Модель связана как с Обработчиком, так с Видом, но Вид не связан явно с Обработчиком
3. Слабая связанность классов - все классы выполняют строго только свою задачу, минимально требуя(в идеале - ссылок быть не должно) ссылки на другие классы. Таким образом, облегчается использования различных классов почти из любого места в коде
3.1. Функциональность "по запросу" (On Demand) - загружаются только необходимые классы и рождаются в минимальном количестве. Например, если мы не используем БД, Модель не будет содержать ссылок ни на какие неиспользуемые классы.
3.2. Универсальная функциональность обеспечена за счет разнообразия классов, а не их "жирности" - используются соотв. подклассы с однообразным интерфейсом нужного процента "жирности"
3.3. кеширование различными бекэндами, сохранение состояния классов и промежуточных результатов в сессии и пул объектов должен, по идее, дать ускорение по времени "подъема" всего стека
4. возможность интеграции с существующими технологиями:
4.1. использования классов из богатой библиотеки Зенда
4.2. ? может быть, каскадная ФС, слизанная из Коханы, хотя в ней больше недостатков, нежели преимуществ (да, можно расширять системные классы, но они в глобальном неймспейсе, и расширение класса одним модулем теряется расширением из другого )
пока что, размышления такие:
1. оставлять ли структуру, как во многих фреймворках (папки application, library\modules, system) или собирать функциональность из кусочков модулей (каждому выделять свои руты, на которые они реагируют)
2. в Windows пути регистронезависимы, и конфигу congig.php рядом с классом Config.php обьявить не удается, более того - если будем искать класс, а найдем конфигу или наоборот, система недоумевает
Все так micron движ очень простой, глобальные переменные в нём действительно есть (мне с ними показалось будет проще, чем с реестром объектов), но по умолчанию их не много: g_config g_lang g_databases (если с БД работаешь) да константа BASEPATH
все остальное "глобалится" в функции IncludeCom и там же двигает кони 🙂 так что не беда на мой взгяд.
+ Людям его очень просто объянить, а зенд мне чесно говоря самому не нравится, написал на нём 3 проекта, но как же там увешаны всем подрят его классы, такая куча функциональности которую я даже представить не могу себе где применить... может я конешно просто туп для нее сейчас, но пока мое мнение такое 🙂 А кохана вроде пошла значительно легче (наверное потому что начал с CI) правда синтаксис си-шный мне не нравицо, хотя и MZZ стилистика тоже не прельщает...
А про идеи конешно круто, многи правда мне напоминают тот же MZZ там тоже правильно сделали что шаблон управляем контроллером а не наоборот, тоже компонентность, кстати там тоже скливальщик всех ксс и js есть 🙂 так что компоненты можно с визуализацией хранить. Классы у них тоже маленькие что приятно, кстати кешер ресурсов (когда пыха картинки и пр. отдаёт) помню как их разлядывал и воровал части в свой (http://www.zmicron.org/?q=coms/browser_data_cache) а вообщем здорово конешно помню я тож хотел написать большой движ, но не потянул - написал этот, и как-то чертовски доволён 🙂
Похоже, каждый уважающий себя php-программист просто обязан написать собственный движок...
Интересно, почему от java-программиста так редко можно услышать фразу "я сейчас переписываю свой web-фрэймвёрк, основываясь на следующих принципах..."
я бы лучше писал на джаве, но:
1. уже есть tapestry5
2. на пхп - есть куча всяких фреймворков, но именно вот такого почему-то нет (как минимум на компонентной основе, а не мвц)
Приходилось работать с битриксом, писать свои компоненты. Не в восторге абсолютно. Код стандартных шаблонов и компонентов - жуткий винегрет.
Кстати, PHP-гуру, как вы храните проекты в системе контроля версий? К примеру, в битриксе код и страницы сайта перемешаны с кодом фрэймвёрка (подозреваю, что во многих движках также). Делаете стандартные бэкапы, предусмотренные фрэймвёрком? Храните в SCM всё вместе, включая код фрэймвёрка? Храните дерево своих файлов отдельно и делаете rsync?
В java-мире каждое веб-приложение и фрэймвёрк - один или несколько архивов, которые могут собираться из независимых источников, легко заменяться и обновляться.
Не знаю как в Битриксе, а в Drupal модули и шаблоны хранятся в отдельных директориях, причем стандартные модули хранятся отдельно от тех, что пользователь устанавливает. Вмешиваться в код ядра необходимости никакой нет, поэтому достаточно следить только за своими модулями.
> шаблоны хранятся в отдельных директориях
В битриксе тоже так, но там эти директории находятся в дереве с кодом движка, а не в собственном поддереве. То есть примерно так:
Пройдите 1 регистрацию, сделайте 2 действия
и получайте от 8950 рублей каждые сутки в автоматическом режиме.
Мы гарантируем:
- Первый заработок в течении 60 минут.
- Стабильный доход 24 часа в сутки.
- Поступление денег без задержек.
- Для России, стран СНГ и Европы.
- Без вложений и установки ПО.
- Специально для новичков и людей без опыта.
Ознакомтесь с условиями у нас на сайте. ( prosto.zarplatt.ru )
и работа всегда есть)
Я, например, удивился когда-то такой "статье": http://ru.wikipedia.org/wiki/From_the_Cradle_to_Enslave
и таких вот 99,9%
>после </html>
>после </html>
Что может быть после </html>?!
А на pochta.ru код ещё страшнее (лень копировать). Самое главное, что браузеры всё, что вставлено после </html>, интерпретируют, как будто тегов </body> и </html> не было.
http://encyclopediadramatica.ch/Hackers_on_steroids
Меня типа заинтересовало, реальный плакат или жаба
Я в основном юзаю, оооо внимание реклама http://www.zmicron.org - тада =)
на сайте микрона убило - " Синие кнопочки основанные на css3 "
сразу видно, для профессионалов !
Прежде чем что-то говорить в код движка глянь... проффисионал блеать 🙂
Zmi = Зайцев Михаил Иванович
Для меня micron проще, и работает хоть по очень упращённой но HMVC модели.
Так же в нём можно отдельно для каждого компонента создавать свой <head> в котором прописывать css и js например, после чего либа ExtraPacker все равно сольёт все это в 1-у css и js-ку. Вообщем удобно то, что не только логика и шаблон разделены и еще и css и js файлы этого кусочка шаблона тоже, есть header_footer-ый шаблон сразу, да и код простой до безумия - открыл index и понял за 10 минут все.
Но все это мелочь на самом деле - просто он не плох, раньше я за частую брал CodeIgniter для простых и Kohana для сложных, а теперь почти всегда на micron-е сижу и вроде как хватает...
> Для меня micron проще
для вас проще потому, что вы его и написали.
> хоть по очень упращённой но HMVC модели
а что такое "очень упрощенная HMVC модель"?
> Так же в нём можно отдельно для каждого компонента создавать свой <head>
вот это уже понравилось
> есть header_footer-ый шаблон сразу
а зачем? во-первых, вы утверждаете, что у вас HMVC, что противоречит с данным утверждением (если только вы как раз это и понимали под HMVC), во-вторых, очень ограничивает в возможностях.
Поясню: например, мне нужно на всех страницах выводить не хедер и футер, а сайдбар - скажем с приветствием навигацией. Причем, приветствие не на всех страницах одинаковое. HMVC подразумевает, что я могу во view шаблона вставить подключение view сайдбара, но это не хедер и не футер.
> - открыл index и понял за 10 минут все.
этим и ограничивается документация?
> CodeIgniter для простых и Kohana для сложных
странное разделение:
1. кохана - это форк CI,
2. разве CI еще не умер?
ну сложно сранивать с тем на чем не работал - потому аргументов и не привел
> хоть по очень упращённой но HMVC модели
под hmvc я имел ввиду компонентная модель mvc и так действительно она сделана, однако по сути ф-я IncludeCom там делает просто несколько require файлов: языкового, контроллера и шаблона, без например CI-шной передачи параметров во вьевре, просто require подрят
> есть header_footer-ый шаблон сразу
А вот под этим я видимо не то имел ввиду, что вы. Попробую пояснить, что хотел сказать 🙂
Очень часто на страницах есть одинаковый шаблон, так вот он может быть занесён в общий template (tpl/main_template.php). Тогда получается такая ситуация например вызывается страница http://www.example.com/users выполняется контроллер users (он может вызвать еще кучу контроллеров, например для прорисовки каждого юзера и пр.) потом получившийся контент (если соответсвующий конфиг еще включен) будет выведен через tpl/main_template.php что бы вывестить в основной "рамке" сайта, а этот main_template.php может вызвать и кучу других контроллеров например сайтбар и навигацию и пр.
Т.е. сам по себе код может быть например таким:
вызываем http://www.example.com/users тогда движ подключает:
1) src/users.php:
$page = Get('p', 1);
$um = new UserModel();
$users = $um->GetList($page);
2) tpl/users.php // здесь будут доступны все переменные которые были в src/users.php, пример без шаблонизатора, так что не ругайте )
<head>
<link rel="stylesheet" type="text/css" href="<?= Root('i/css/users_list_design.css')?>" />
</head>
<div class="users">
<?php foreach ($users as $uid => $u)
{
// Тут включиться src/one_user, tpl/one_user которая тоже может свои css/js содержать
IncludeCom('one_user', array('user_id' => $uid)); // можно переменные в компонент вставлять
}
?>
</div>
ob_start();
IncludeCom($_GET['query']); // в query например users может быть
$content = ob_get_clean();
IncludeCom('main_template', array('center_page' => $content)); // в tpl/main_template главный хед и боди сайта наример
> открыл index и понял за 10 минут все.
С докой действительно пока беда, как и с набором компонентов есть нормальные:
например рассказывающие о простой дефолтной модели: http://www.zmicron.org/?q=coms/def_model
а есть которые вставил чисто что бы инфа под рукой была (дефолтная ксс-ка для оконной рамки)
> CodeIgniter для простых и Kohana для сложных
Кохана с 3-ей версии уже не форк был, сейчас отдельно ветки 2-ая (форк CI) и 3-ая которая целиком с 0-ля.
А CI все еще жив, не так давно даже обновлялся в англ сигменте 🙂
Ну а вообще в нём много удобных вещей, которые при этом не сложно заменить:
1) включен уловитель ошибок Debug_ErrorHook (от dklab)
2) при желании можно скачать в компонентах дефолтную модель которая как бд юзает DbSimple и профайлер
3) есть XDebug профайлер для отлова, тож в компонентах
3) куча визуальных плющек подключаемых, например слайдер jquery-tools (тож в компонентах)
Подключается в нужное место вот так:
<?php IncludeCom("slider_head")?> // js и css (потом солются в одну)
<?php IncludeCom("slider", array("panels" => array("test 1", "test 2", "test 3")))?> // контент панелей
Просто не всегда надо и потому сам движ по дефолту пустой.
наверное, несложные проекты летают, но для более серьезных есть минусы:
1. функции и переменные определены глобально
2. шаблон (layout) один для всех
3. многие вещи, как, например, загрузка классов, все равно приходится дописывать самому
+. а где руты, работа с базой, проверка и фильтрация данных и т.д.?
кроме того, всякие эти котеровские "уловители" морально устарели.
1. Компонентная модель: в одной папке компонента (и подпапках) находится все, связанное с ним - код, шаблон(ы), стили, скрипты, конфига, языковые файлы и т.д.
1.2. Именование и расположение классов соответствует Zend Naming Conventions (Класс Package1_Package2_Class находится в /Package1/Package2/Class.php)
2. MVP и Passive Template - вид и поведение компонента определено в шаблоне (Вид), а не в контроллере, при этом управляющего кода в шаблоне нет.
2.1.Зато есть связанный с ним Обработчик(типа Контроллера), который реагирует на ввод (подача формы), но изменяет только Модель
2.2.Модель связана как с Обработчиком, так с Видом, но Вид не связан явно с Обработчиком
3. Слабая связанность классов - все классы выполняют строго только свою задачу, минимально требуя(в идеале - ссылок быть не должно) ссылки на другие классы. Таким образом, облегчается использования различных классов почти из любого места в коде
3.1. Функциональность "по запросу" (On Demand) - загружаются только необходимые классы и рождаются в минимальном количестве. Например, если мы не используем БД, Модель не будет содержать ссылок ни на какие неиспользуемые классы.
3.2. Универсальная функциональность обеспечена за счет разнообразия классов, а не их "жирности" - используются соотв. подклассы с однообразным интерфейсом нужного процента "жирности"
3.3. кеширование различными бекэндами, сохранение состояния классов и промежуточных результатов в сессии и пул объектов должен, по идее, дать ускорение по времени "подъема" всего стека
4. возможность интеграции с существующими технологиями:
4.1. использования классов из богатой библиотеки Зенда
4.2. ? может быть, каскадная ФС, слизанная из Коханы, хотя в ней больше недостатков, нежели преимуществ (да, можно расширять системные классы, но они в глобальном неймспейсе, и расширение класса одним модулем теряется расширением из другого )
1. оставлять ли структуру, как во многих фреймворках (папки application, library\modules, system) или собирать функциональность из кусочков модулей (каждому выделять свои руты, на которые они реагируют)
2. в Windows пути регистронезависимы, и конфигу congig.php рядом с классом Config.php обьявить не удается, более того - если будем искать класс, а найдем конфигу или наоборот, система недоумевает
все остальное "глобалится" в функции IncludeCom и там же двигает кони 🙂 так что не беда на мой взгяд.
+ Людям его очень просто объянить, а зенд мне чесно говоря самому не нравится, написал на нём 3 проекта, но как же там увешаны всем подрят его классы, такая куча функциональности которую я даже представить не могу себе где применить... может я конешно просто туп для нее сейчас, но пока мое мнение такое 🙂 А кохана вроде пошла значительно легче (наверное потому что начал с CI) правда синтаксис си-шный мне не нравицо, хотя и MZZ стилистика тоже не прельщает...
А про идеи конешно круто, многи правда мне напоминают тот же MZZ там тоже правильно сделали что шаблон управляем контроллером а не наоборот, тоже компонентность, кстати там тоже скливальщик всех ксс и js есть 🙂 так что компоненты можно с визуализацией хранить. Классы у них тоже маленькие что приятно, кстати кешер ресурсов (когда пыха картинки и пр. отдаёт) помню как их разлядывал и воровал части в свой (http://www.zmicron.org/?q=coms/browser_data_cache) а вообщем здорово конешно помню я тож хотел написать большой движ, но не потянул - написал этот, и как-то чертовски доволён 🙂
и склеивальщик css и js тоже сработает только если через смарти вставлены линки на них.
Интересно, почему от java-программиста так редко можно услышать фразу "я сейчас переписываю свой web-фрэймвёрк, основываясь на следующих принципах..."
1. уже есть tapestry5
2. на пхп - есть куча всяких фреймворков, но именно вот такого почему-то нет (как минимум на компонентной основе, а не мвц)
Кстати, PHP-гуру, как вы храните проекты в системе контроля версий? К примеру, в битриксе код и страницы сайта перемешаны с кодом фрэймвёрка (подозреваю, что во многих движках также). Делаете стандартные бэкапы, предусмотренные фрэймвёрком? Храните в SCM всё вместе, включая код фрэймвёрка? Храните дерево своих файлов отдельно и делаете rsync?
В java-мире каждое веб-приложение и фрэймвёрк - один или несколько архивов, которые могут собираться из независимых источников, легко заменяться и обновляться.
В битриксе тоже так, но там эти директории находятся в дереве с кодом движка, а не в собственном поддереве. То есть примерно так:
И такие "островки" по всему дереву каталогов. Неудобно же хранить в scm...
Может ты еще и боярышник пил?
и получайте от 8950 рублей каждые сутки в автоматическом режиме.
Мы гарантируем:
- Первый заработок в течении 60 минут.
- Стабильный доход 24 часа в сутки.
- Поступление денег без задержек.
- Для России, стран СНГ и Европы.
- Без вложений и установки ПО.
- Специально для новичков и людей без опыта.
Ознакомтесь с условиями у нас на сайте. ( prosto.zarplatt.ru )
В предлагаемую нами услугу “Трастовые площадки” входит:
— База – 400 трастовых сайтов
— Создание специальной почты при регистрации
— В почтовом ящике – более 100 писем подтверждений с площадок
— Регистрация осуществляется профессионалом вручную
— Подтверждение писем активации проходит вручную
— Описание составляет опытный, грамотный специалист-копирайтер
— В отчет входит список страниц со ссылой Вашего сайта
— Почтовый ящик с письмами передается заказчику
— Максимальный срок выполнения работ – 15 дней.
-$$-